Go Back   Exetools > General > General Discussion


Thread Tools Display Modes
Old 09-16-2015, 03:03
Dreamer's Avatar
Dreamer Dreamer is offline
Join Date: May 2012
Posts: 602
Rept. Given: 615
Rept. Rcvd 659 Times in 257 Posts
Thanks Given: 117
Thanks Rcvd at 168 Times in 126 Posts
Dreamer Reputation: 38
Password Encryption

what should be best for encrypting passwords for forums,emails,etc
Reply With Quote
Old 09-16-2015, 03:41
atom0s's Avatar
atom0s atom0s is offline
Join Date: Jan 2015
Posts: 375
Rept. Given: 26
Rept. Rcvd 116 Times in 59 Posts
Thanks Given: 54
Thanks Rcvd at 670 Times in 263 Posts
atom0s Reputation: 100-199 atom0s Reputation: 100-199
For passwords on a forum you would want to hash them, not encrypt them. There should never be a undo method for a password. Along with the hashing, you should be appending a random long-generated salt to the password before it is hashed to help increase the security of the password and toughness to ever bruteforce it.

For example, if you use a hash algorithm such as SHA256/SHA512, let's use the password 'abc123' as an example.

SHA256: ecd71870d1963316a97e3ac3408c9835ad8cf0f3c1bc703527c30265534f75ae
SHA512: daef4953b9783365cad6615223720506cc46c5167cd16ab500fa597aa08ff964eb24fb19687f34d7665f778fcb6c5358fc0a5b81e1662cf90f73a2671c53f991

In a brute force or dictionary attack, abc123 will take less then 30 minutes to break on modern machines. This would render just storing the direct hash as a insecure method of handling the password. That is where salts come in to play to make things much more secure.

You would append a random generated salt to the password before it is hashed to generate a much more difficult hash to break. For example:
Our password: abc123
Our random hash: w]q!!*z+4~02)@gxxfK;;v6,S!*,}1&$EbURm$f[8*{/E,y&-kG@ sJ#?W lq;1+

Which would make the following hashes:

SHA256: e9c349fdbf269f1f80c934dc72ae776d2b0d69bc3bcc3f8568a65a861422d268
SHA512: 7266f6d6c38de04333932578a2f7252febcb2893874958587b475bac09ad121b2ec319b60dbf8b02fa9a19c0c953d0fd05bd3de2a02629145a917d05b41b609d

A dictionary attack will never be able to break this as it is not something in a dictionary. And a brute force attack against a hash like this is nearly impossible to ever complete successfully.

Keep in mind when you choose a hashing algorithm though, things like MD5/SHA1 are frowned upon as they are outdated, have collisions and have many rainbow tables and such made to help aid in cracking of passwords.

For things like emails, you would want encryption. AES is the common standard today of encrypting anything. But many other algorithms should be sufficient as long as there is no security issues like sharing of the needed decryption key in a manner that invalidates the encryption in the first place.
Reply With Quote
The Following User Gave Reputation+1 to atom0s For This Useful Post:
Dreamer (09-16-2015)
The Following 3 Users Say Thank You to atom0s For This Useful Post:
Dreamer (09-16-2015), ontryit (10-20-2015), p4r4d0x (10-16-2015)
Old 09-22-2015, 18:05
Mkz Mkz is offline
Join Date: Jan 2002
Posts: 98
Rept. Given: 0
Rept. Rcvd 2 Times in 2 Posts
Thanks Given: 5
Thanks Rcvd at 25 Times in 17 Posts
Mkz Reputation: 2
The question is a bit ambiguous, it all depends on whether you need to "scramble" it to then use to:
1) log in to a forum or to a webmail (a vault of the passwords YOU use), or
2) validate that someone logging in to a forum you manage is indeed providing the right password (securely validate users' credentials)

@atom0s' answer is for the situation 2.
Indeed, NEVER do any kind of encryption, as its reversible nature could make you liable for leaking your user's original password data, which would then result in possible reusing them in other forums or other kinds of web credentials, in case you (as a provider of the forum) get hacked and the database is stolen.

I do have some minor remarks to improve the answer, though

While the salt is indeed something you should definitely add, it does not prevent an attacker to try to break each individual password - with dictionary attacks, for instance.
If your database gets stolen, the salts are there as well - you *need* them when doing the validation, to know that *that* salt for that user + abc1 does result in that hash you stored. If you don't keep the salt, you have no way of knowing if the user-provided password will turn into the hash you stored.

Additionally, each user on the database should have his own random salt, so that identical passwords for multiple users result in completely different password hashes.

The way to prevent (or harden) brute forcing is introducing a load factor - a repetition of the number of iterations (MD5, SHA256, whatever) that both the legitimate forum code and also a bruteforcer must execute till it arrives to the final result.
Running an MD5 of a certain input + salt takes X ms. But running it 1 million times, for instance, will take 1 second. If a brute forcer needs to spend 1 second of active CPU to test each possible password, you can see it's much harder to do a brute force or even a dictionary attack.
The downside is that the forum server will take 1s to validate a legitimate user login. A balance must therefore be achieved.

There are lots of details to take into account when trying to design the possible safest way to handle user credentials.
One of many possible guides can be found on this OWASP page: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
The main aspects mentioned there:
  • Unique salt for each usage (not even reuse it for multiple passwords of the same user)
  • Also add a site-wide key / HMAC that won't get stored on the database and thus *might* not be available if only the DB is stolen
  • Introduce a work factor (reduce feasibility of brute force even if all data is stolen)

And above all: design the system assuming all the data will get stolen eventually.

Also, and if you want to laugh a bit, here's a pretty nice article showing what NOT to do: https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/
You can even play crosswords with the user's hashes and password hints
Reply With Quote
The Following User Gave Reputation+1 to Mkz For This Useful Post:
Dreamer (09-22-2015)
The Following User Says Thank You to Mkz For This Useful Post:
Dreamer (09-22-2015)
Old 10-16-2015, 13:55
foosaa foosaa is offline
Join Date: Dec 2005
Posts: 99
Rept. Given: 34
Rept. Rcvd 11 Times in 9 Posts
Thanks Given: 152
Thanks Rcvd at 75 Times in 29 Posts
foosaa Reputation: 11
I would prefer PBKDF2. Nothing beats it currently.

Using SHA with Salt too is not considered to be secure.

Using HMAC is also not secure enough. I prefer to link to an article which you can read and decide.


I always go by PBKDF2 (Password Based Key Derivation Function version 2). It gives amble security and currently do not have any know weakness. Also, bruteforcing is way too costly and time consuming and thus offers good protection.

If you prefer some kind of obscurity, hash the email ids as well. Matching them against the hashes *will* be as simple as a normal email 'select' query from the db, but offers privacy. In case if the database gets leaked, the attacker has no way of knowing what the email id is! I have done that and it is a peace of mind since the email ids are also not exposed. Of course, there is a load on the server for multiple PBKDF2 operations, but my user information is protected in terms of email + password! I prefer to do that for the login information which could be potentially used to identify the user and cause a risk to his privacy. The only caveat is that, email id will not be available for any other operations because you don't have it. I use a unique GUID kind of id (unique user id) / string associated with the logic to perform all other mapping operations instead of using the email (if email was used for any operations).

Hope it helps. Thanks.

Last edited by foosaa; 10-16-2015 at 14:02. Reason: Updated with more information.
Reply With Quote
The Following User Gave Reputation+1 to foosaa For This Useful Post:
niculaita (10-16-2015)
The Following User Says Thank You to foosaa For This Useful Post:
niculaita (10-16-2015)
Old 10-19-2015, 18:02
Mkz Mkz is offline
Join Date: Jan 2002
Posts: 98
Rept. Given: 0
Rept. Rcvd 2 Times in 2 Posts
Thanks Given: 5
Thanks Rcvd at 25 Times in 17 Posts
Mkz Reputation: 2
PBKDF2 is a very common way to achieve the "work factor" I mentioned in my response, yes.
I agree that if the number of iterations is properly set, it should be secure for most purposes. But still, there are alternatives to it, namely bcrypt and scrypt, because custom-built hardware can reduce the cost of bruteforcing. You can check the details on the wikipedia section about these alternatives: https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2

Still, while using the work factor is indeed a must (and I agree that PBKDF2 should be sufficient), it is not enough.
If you don't use a unique salt, an attacker can immediately identify whether there are any passwords that are reused for several users.
The last link on my previous post, which describes the Adobe case, is a great illustration of how bad it is if there's no unique salt in each entry. Even if you can't break the passwords, just knowing that some of them are the same is something you should avoid (and the salt makes it easy to achieve). Things like the password hint are also very sensitive, and those will require reversible encryption.

Finally, the HMAC aspect is also something to consider.
While it won't help if the entire system is compromised, it will make it impossible to do any kind of attack provided only the database is stolen, but not the application code that is generating and validating the hashes.
In Adobe's case, they were using reversible encryption (3DES) instead of all the hashing techniques we're discussing, but AFAIK the key wasn't stolen, or at least made public. Without such key - or the HMAC one - you might "play crosswords" with identical hashes for different users, but you won't be able to brute force anything.
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

All times are GMT +8. The time now is 23:46.

Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( 1998 - 2022 )