Password Security


Passwords are commonly used for proving of identity and authorisation purposes. There have been many forms of identification and authorisation methods that includes the use of cryptographic tokens and one time use authentication codes. Regardless of how advance identity management tools are advancing, the password / passphrase / passcode / PIN is still the most common way of identification whether we like it or not. It is very easy to setup a password-based authentication system with very minimal efforts which uses a backend database of some form and a password checker that checks if the submitted password matches the user in a password database.

This topic would touch on the vulnerability of the passwords stored in the database which have been subjected to many types of security improvements and their weaknesses whenever a password database is compromised.

Whenever a password database is leaked, we have to assume that anyone has access to the entire password caches on the password database and could reverse lookup and use these leaked passwords to compromise other infrastructures of those users in the leaked password database. We also need to keep in mind that since the password database is now available for downloading offline and presuming that the algorithm for computing any password hashes/encrypted password algorithms are known, the user have virtually all the time he/she needs to bruteforce the password within a reasonable amount of time.

The common form of password cache defense is to hash the password so that the raw password would never be known and only the password hashes would be matched and used for authentication purposes. Most of the common password hashing algorithms would be the MD5 and SHA1 hash for their simplicity and availability in most programming environment libraries. MD5 have been shown to be broken and SHA1 is close to being broken. The alternate to MD5 and SHA1 would be to use stronger hashes like the SHA2 and SHA3 family of hashes. These hashes would provide very little challenge for a bruteforce attack since a cluster of computers or highly customized chipboards could quickly break the hashes by bruteforce or with rainbow hash tables within reasonable amount of time span (a few hours to a few days in a well funded setup or via cloudcracking).

Password algorithm designers resort to adding something called a salt into the hashes so that a rainbow table which is something like a precomputed wild-card of possible passwords into hashes, would add to the cost of creating an "all-knowing" rainbow table to make bruteforcing much more expensive. Many other methods of making bruteforcing much more slower and expensive is to use specially tweaked algorithms that would increase the cost per computation of a single permutation of a hashed password. BCRYPT and SCRYPT are known to be computationally expensive in terms of CPU and GPU respectively to discourage the use of CPUs and GPUs to speed up bruteforcing of offline password caches.

Some have resorted to password encryption by using a strong cryptographic algorithm and scheme to encrypt a password to prevent knowledge of the password. Such a scheme may work if the encryption keys are stored separately and safely away from the compromised servers. Of course the misuse of cryptographic operations and mishandling of encryption keys would leak the nature of the passwords or may allow a pattern in the passwords to be spotted but generally a properly implemented set of strong cryptographic algorithm and scheme plus proper crypto-OPSEC would ensure the security of the passwords according to the security guarantees promised by the algorithms and the schemes. Cryptography may seem to be something easy to implement but is actually hard to do correct and most people shun cryptography for the part that it is still a rather "hard science" to learn and get correct.

What I would suggest is the use of a mixture of techniques to not only hide the password but to also make it computationally harder to bruteforce the password by using a mixture of interweaving the BCRYPT and SCRYPT algorithms to form a computationally expensive password hash (both BCRYPT and SCRYPT uses salt as well) and wrapped with a layer of encryption managed by a Hardware Security Module (HSM) that would safely store the cryptographic keys in the secure memory of the HSM. This tehcnique could be rinsed and repeated for a few more additional rounds before deriving an ecnrypted and hashed password value that would make an offline attack implausible due to the participation of an online object (HSM) that escrows the encryption key(s) within it's safe memory.

There are also proposals of splitting passwords onto a few more servers and splitting the encryption keys of each password onto some servers and a minimal threshold of servers are required to access the encrypted password and the encryption key that encrypts the password which would make it harder for compromised servers lower than the threshold to succeed into reconstructing the encryption keys to decrypt the reconstructed passwords. Such methods are very powerful but the increased complexity may turn out to be an inconvenience unless there are readily available trusted source codes in the open source community for use.

One final method of password authentication would be to not direclty apply the password as the authenticator but to create a "game" or a cryptographic protocol that would take a harmless unique value called a nonce to be shuffled between the client and the server. Since the client claims to know the proper authentication code and the server possess the user's authentication code. The authentication code is not the password itself but a permuted variant of the password. One possible technique is the use of a MAC algorithm to transform a username or user email under the influence of an encryption key which would usually be derived from a password. In a simple term, the password would be stretched into a proper length MAC cryptographic key and the MAC algorithm (like the Poly1305-AES and HMAC-SHA1 algorithm) would be applied onto some form of identifier like a username or email that the user knows and this would churn out a unique code value that only the owner of a proper password and identification would be able to re-create. On the server side, the stored unique authentication code would not directly lead to the password as the algorithm is a cryptographically secure one-way algorithm that ensures working backwards using the authentication code to derive the encryption keys (hence the password) is computationally hard and implausible. The use of BCRYPT and SCRYPT to make the strecthing of the password into an encryption key computationally expensive would also be preferrable to slow down possible bruteforce of trying out passwords to derive the plausible cryptographic key. Finally, when the "game" starts, the server would issue a challenge nonce to the client which the client would use it's derived authentication code to encode the nonce and send back to the server. The server would use it's stored authentication code to decode the nonce and if the nonce it sent as a challenge matches the nonce encoded, the authentication is proven to be correct. Sending the nonce instead of authentication code is to prevent interception and decoding of the highly confidential authentication code if it were to be sent during transmission whereas sending a coded nonce would be kind of meaningless as it is only used once and discarded. If a leak of the authentication codes were to take place, the authentication codes would not reveal the passwords and can be easily replaced when needed in the password cache during emergencies.

From the above article, I would highly recommend the encryption and hashing of passwords using a HSM as stated above or, for those who cannot afford a HSM, to use the final password authentication via a "game" and authentication codes.


Publication Info
Published On: 25th Dec 2014
Author: Thoth


CONTACT