News To Day India

1. User vs. password

Whenever hacker gets access of the id of the user than he can use it for lifetime/prolonged period. Most of the time common people never change the password I would like to suggest them treat your password as under, you should change it daily or weekly or else it can be proved harmful to you as the attacker can impersonate the user for prolonged period. It isn’t much better for the companies too when they don’t change there password for months because if they change password once in a month than it still give hacker a lot of time to perform malicious actions.
I strictly advise People to use strong passwords (a strong password consist of lower and upper case letters, digits, special characters; the more random more better), password should be unique for every system. This is fine from security point of view, but unusable from a user point of view. As a result, people take the passwords down, stick them on the monitor or hide under the keyboard. They also use the same password for different systems. When this is a case, the attacker can automatically impersonate the user in many places.

2. Plaintext vs. hash

Passwords are sometimes stored in plaintext. Then the attacker knows the password instantly after breaking in (via SQL injection for instance). That’s why it’s better to store a hash of the password, which is denoted by H(P) in the article (H ? hash function, P ? password). The ideal hash function is irreversible (the attacker cannot get the password from the hash) and there are no two different passwords P1 and P2 such that H(P1) = H(P2).
Let’s assume that the hash of the password is stored in the database. The user enters his username and password to authenticate. The hash of the entered password is calculated and compared with the hash stored in the database. If they match, the user is authenticated.


3. Salting

The salt (denoted by S in the article) is a long mixture of random characters stored in the database (plaintext). In addition, H(P+S) is calculated and stored in the database where the sign ‘+’ denotes the concatenation of P and S. The user enters username and password to authenticate. The salt (S) is taken from the database and concatenated with entered password (P). Then H(P+S) is calculated. If it matches the hash stored in database, the user is authenticated.
Let’s assume that the attacker got access to the database. He knows the salt and H(P+S). The pre-calculated dictionary contains probable passwords and their hashes. The salt is long and random. That is why the probability of finding H(P+S) in this dictionary is close to zero. This way pre-calculated dictionary attack is prevented.
The attacker who got access to the database knows S and H(P+S) and can perform dictionary attack. He calculates H(PP1+S), H(PP2+S), H(PPN+S), where PP1, PP2, PPN is the list of probable passwords (dictionary). If one of these hashes matches H(P+S), the attacker will find out the user’s password.
If there were one salt for every user, the attacker would need to perform the mentioned above calculation once in order to find the users, who have passwords included in the dictionary. That’s why it is recommended to use unique salt for every user. Then the attacker has to perform the calculation N times, where N is the number of users. In the meantime, the users can change their passwords when the intrusion has been detected. That’s why unique salt for every user is used to slow down the attacker.
It is also possible to add additional salt (denoted by S2 in the article) ? the one not stored in the database and common for all users. When the attacker gets access to the database via SQL injection, he can’t find out S2. That’s why the attacker can’t calculate H(PP1+S+S2), H(PP2+S+S2), H(PPN+S+S2). Consequently, dictionary attack is prevented. It works if the attacker has only access to the database. When the attacker gets access to the machine, he can learn the S2 and perform a dictionary attack.