Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
Safely Storing User Passwords: Hashing vs. Encrypting
Newest First  |  Oldest First  |  Threaded View
Jose ManuelG297
50%
50%
Jose ManuelG297,
User Rank: Apprentice
7/14/2017 | 11:56:35 AM
Re: Good overview
Nice article, there's another issue that needs to be taken into account: the moment when you hash.

In a typical multi-tier architecture, the user application (client) requests the password which is then sent to a server during the login time. Subsequent requests usually use a session token.

The hashing of the password can be done either on the client side, on the server side, or on both.

1- If done by the client, even if the communication channel is attacked, the original password is safe, avoiding the login through the application client user interface... but towards the server, the hashed password is effectively the password, so if we get to the hash password database, we can authenticate against the server.

2- If the hashing is done at server side, the problem is that the password needs to be secured while in transit.

3-A mixed of both is to encrypt or hash between the client and the server, and again on the server side. This looks the safest way to me.

I would like to know your thoughts about it...

Thanks and best regards
dgp101
50%
50%
dgp101,
User Rank: Apprentice
9/7/2016 | 8:54:39 PM
Re: Good overview
Good question. The point of the salt is that it is different for each account. It's true that you could use it, together with the knowledge of the hashing algorithm and number of iterations, to produce one rainbow table for each user, one user at a time. However, without the salt you just make the rainbow table once -- even before compromising the system -- and then compare every user's hash to your rainbow table and reveal many passwords quickly.

With a hash, you have to (1) wait till you know my salt to make the rainbow table for my account, and (2) when/if you find one match, that's the only one you'll get with it because every password in the table also has a unique salt.

Finally, using "slow" hashing algorithms with many cycles can increase the amount of time per attempt to a point where even making one complete rainbow table should take years. That works in concert with the salt: The salt makes you do X amount of work per user you want to crack instead of X amount of work to get "All/most users" - and the iterations (slowness) make you do 1000X the amount of work PER attempt. These two work together to make cracking too costly to be useful. Ideally that cost should be on the order of requiring a large cluster of dedicated hardware to churn for many years to crack one password. That's good since future hardware will be faster than today's.
rhusain0
50%
50%
rhusain0,
User Rank: Apprentice
11/17/2015 | 3:39:35 PM
Re: Good overview q re password transmission
How do u handle securing password transmission on over the air. Or capture of hash over air Im doing password for iot and looking for best practices Rafe
rhusain0
50%
50%
rhusain0,
User Rank: Apprentice
11/17/2015 | 3:39:33 PM
Re: Good overview q re password transmission
How do u handle securing password transmission on over the air. Or capture of hash over air Im doing password for iot and looking for best practices Rafe
TejGandhi1986
50%
50%
TejGandhi1986,
User Rank: Apprentice
6/13/2014 | 9:01:50 PM
Preventing the password file from getting stolen
Thanks for the article,itis very informative and provide details on the foundations related to hashing and encryption.

Considering different chain of thoughts ,along with encryption and hashing that is used to secure passwords it is essential that the password file is well protected SAM file in windows and etc/shadow or etc/passwd file in Linux access must be restricted with multiple layers of defense to prevent it from getting stolen.

Thanks

Tej Gandhi

 
MichaelCoates
100%
0%
MichaelCoates,
User Rank: Author
6/12/2014 | 4:16:00 PM
Re: Good overview
Good question. The stolen database would indeed include the salts. However, exposure of random per-user salts does not undermine their purpose and security benefits.

There are two benefits to using per-user salts

1. When using per-user salts an attacker cannot simply review the stolen password hash databse for duplicate hashes (which would indicate the same original password for both accounts). The introduction of a per-user salt ensures that even the same password will result in unique hashes.

2. An attacker cannot download a rainbow table and use it against the password hashes. A rainbow table is a large database of precomputed hashes for a variety of common passwords (or even all possible passwords of certain character sets and lengths). Without per-user salts an attacker could do a simple lookup of the stolen hash within the rainbow table to determine the original password. The introduction of per-user salts means the rainbow table is useless.


Sure, an attacker could incorporate the salt into a brute force attack. But the purpose of a salt isn't to stop brute force. It's to accomplish the two items mentioned above (duplicate hashes and rainbow tables). As I mentioned in the article, the iterative hashing approach that exists in bcrypt/scrypt/PBKDF2 is the defense against brute force attacks on the password hash.

 

Hope that helps.

Michael

 
chiefwilson
50%
50%
chiefwilson,
User Rank: Apprentice
6/11/2014 | 9:57:04 PM
Re: Good overview
Michael,

Thank you for a well-written article. I agree that hashing passwords with added salt provides far greater security than simply encrypting passwords. My question is simple: If a malicious actor steals a database of password hashes, won't this database include the salts as well, thereby nullifying the purpose of the salt, which is to defend against brute force dictionary and rainbow table attacks?
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
6/4/2014 | 2:51:46 PM
Re: Good overview
Thanks, Michael. One of the things I've been hearing about more and more is that personal information has become much more valuable a target for cybercrime than, for example credit cards. If that's the case, then your message about hashing versus encryption is one that InfoSec pros should definitely take to heart. 
MichaelCoates
100%
0%
MichaelCoates,
User Rank: Author
6/4/2014 | 1:02:50 PM
Re: Good overview
The largest misconception is that since encryption is good for protecting information in some situations it is therefore appropriate for all situations involving sensitive data. As discussed above, encryption is really the wrong choice for protecting passwords.

Second, that any hashing algorithm is sufficient for password hashing. Selecting a weak algorithm like md5 or failing to user per user salts places passwords at extreme risk if the hash file is stolen.

-Michael
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
6/4/2014 | 12:34:09 PM
Good overview
Thanks for your detailed overview, Michael. You say that to propertly secure user invormation today, application developers must starts with "a proper understanding of fundamental security controls and the protection of user passwords using modern hashing algorithms." What do you think is the biggest misunderstanding of security that app developers have?


Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
MITRE Releases 2019 List of Top 25 Software Weaknesses
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16531
PUBLISHED: 2019-09-20
LayerBB before 1.1.4 has multiple CSRF issues, as demonstrated by changing the System Settings via admin/general.php.
CVE-2019-9717
PUBLISHED: 2019-09-19
In Libav 12.3, a denial of service in the subtitle decoder allows attackers to hog the CPU via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c has a complex format argument to sscanf.
CVE-2019-9719
PUBLISHED: 2019-09-19
A stack-based buffer overflow in the subtitle decoder in Libav 12.3 allows attackers to corrupt the stack via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c misuses snprintf.
CVE-2019-9720
PUBLISHED: 2019-09-19
A stack-based buffer overflow in the subtitle decoder in Libav 12.3 allows attackers to corrupt the stack via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c misuses snprintf.
CVE-2019-16525
PUBLISHED: 2019-09-19
An XSS issue was discovered in the checklist plugin before 1.1.9 for WordPress. The fill parameter is not correctly filtered in the checklist-icon.php file, and it is possible to inject JavaScript code.