Apr 4, 2003Mårten Trolin1 Previous lecture TLS details –Phases Handshake Securing messages –What the messages contain –Authentication

Apr 4, 2003Mårten Trolin2 Today’s program – passwords Passwords for authentication –Storing hashed passwords –Use of salt Passwords for key generation –PKCS#5

Apr 4, 2003Mårten Trolin3 Passwords for authentication Simple way to achieve authentication. –Does not require any special hardware. Users tend to choose simple passwords. –Counter-measures exist. Storing passwords requires extended security measures. –Security breach in password database has major consequences.

Apr 4, 2003Mårten Trolin4 Password authentication – different approaches Password sent in plain and stored in clear in the database Password hashed by client and sent to the server. Password hash stored in database. Password sent in plain to the server. Password hashed by server. Hash compared to hash in database.

Apr 4, 2003Mårten Trolin5 Password stored in clear User Server User enters password p p Server compares p with the value stored in its database. If the values match, user is allowed.

Apr 4, 2003Mårten Trolin6 Password stored in clear If Oscar captures the password database, he can log in as any user.

Apr 4, 2003Mårten Trolin7 Password sent as hash User Server User enters password p User computes the hash H(p) H(p) Server compares H(p) with the value stored in its database. If the values match, user is allowed.

Apr 4, 2003Mårten Trolin8 Password sent as hash If Oscar captures the database with the hashed passwords, he can log on as any user. –Since only the hash is stored, Oscar will not know the passwords. –Because only the hash is needed to log on, Oscar can log on anyway.

Apr 4, 2003Mårten Trolin9 Password hashed by server User Server User enters password p p Server computes the hash H(p) and compares the value with the database. If the values match, user is allowed.

Apr 4, 2003Mårten Trolin10 Password hashed by server If Oscar captures the database with the hashed passwords, it gives him little information. –Since only the hash is stored, Oscar will not know the passwords (provided a good hash is used). –Without the passwords, Oscar cannot log on.

Apr 4, 2003Mårten Trolin11 Capturing the password database What happens if Oscar captures the password database with hashed passwords? Since he only has the hashes, he cannot retrieve the passwords. If the users of the systems chooses bad passwords, Oscar can try to hash common words until he finds a hit. –To speed up the attack, Oscar can even store a list of commonly used passwords, and compare the password database to his list. –This is called a dictionary attack.

Apr 4, 2003Mårten Trolin12 Password authentication over unsecure lines All the methods discussed require the server to be authenticated and the communication to be secure. If this is not the case – the only common information is the password – other methods must be used. Such methods exist, but are outside the scope of this course...

Apr 4, 2003Mårten Trolin13 Salt To slow down a dictionary attack, instead of storing H(p) in the database, we H(p | s), the hash of the password concatenated with a string s. The string s is called the salt. The salt can be stored in clear in the database. Its purpose is to prevent the use of precalculated lists. –Since. in general, H(p | s 1 ) ≠ H(p | s 2 ), Oscar would need one precalculated list per salt. With a salt that is long enough,this becomes infeasible. –Also, the use of salt prevents the detection of a user having the same password on several systems.

Apr 4, 2003Mårten Trolin14 Avoiding bad passwords Users choosing weak passwords pose a security risk. Several counter-measures exist: –Education. –Automatic password checking Compare with lists of known passwords. Demand that passwords are of a certain length. Tip: Using the term pass phrase may give the user an idea that the password should be long enough. –Minimizing the loss in case of security breach Forcing the users to change passwords regularly means Oscar can only use the password he has found a certain time.

Apr 4, 2003Mårten Trolin15 Passwords for key generation It is quite common to use a password for generation of a symmetric key. –Password protection of a private key. –Encryption of backups. We want a key generation function that takes as input a password p and outputs a key k.

Apr 4, 2003Mårten Trolin16 Password generated keys – problems and solutions Password generated keys suffer from the same general problem as passwords for authentication. –Number of passwords is relatively small – possible to create a list with all possible passwords and corresponding keys. Use a salt to avoid dictionary attacks. Make key generation “slow”, to make brute-force attacks more time consuming.

Apr 4, 2003Mårten Trolin17 Iterations In order to make brute-force attacks harder for the opponent, we want the key generation not to be too fast. –If key generation takes.5 seconds, this is not a problem for the legitimate user. –However, for the opponent, who needs to try a large number of keys, this makes his work considerably harder. Key generation from passwords should include a some kind of loop, and the number of iterations should be possible to configure. –Parallelizing the loop should not be possible.

Apr 4, 2003Mårten Trolin18 PKCS#5 The RSA standard PKCS#5 specifies a method to derive key material from passwords. –Produces key material of arbitrary length. PKCS#5 uses a salt and a configurable number of iterations. –A minimum of 1000 iterations is recommended. Implemented in many cryptography library.