|
Great article, agreed. But he doesn't cover when to hash in a web app.
If I enter a password on a webpage, shouldn't I hash the password before I send it to the server?
If I retrieve the salt into the webpage from the server first and then hash the password before sending to the server, doesn't that have security implications too?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
If the hash would be calculated at the client, then the salt is needed at the client. When logging in, the user name has to be sent to the server, and then the salt would be sent back for that user, regardless of the password. So anybody would be able to retrieve salts, which would render them useless.
Wout
|
|
|
|
|
Exactly my point. So, you'd need to do something else between client and server to secure the account id and password.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Ofcourse, you need SSL to secure the password transfer. But even with SSL it wouldn't be a good idea hashing at the client because anybody could get anybody else's salt.
Wout
|
|
|
|
|
Salts are not meant to be secret. That's the beauty of salts. They are only used to prevent rainbow attacks and are not there for additional secrecy (as the article also mentions by the way). So it's no problem to publish the salt of every user account.
|
|
|
|
|
Ah yes, you are most definitely right, thanks for correcting me!
Wout
|
|
|
|
|
The following is the response I received from the article's author, after asking the same question via email:
----- Start Email Response -----
Hi,
Here's a copy-pasted email I just sent someone who asked a related question:
------
Even if you are hashing the password on the client side, you still have
to hash on the server. Because if you just hash in the browser, then the
hash "becomes" the password in the sense that the hash value is all an
attacker needs to get in to someone's account. If a bad guy hacks into
the database storing all of these values, then he'll have immediate
access to every account.
So regardless of what you do in the browser, you still need to hash on
the server.
[ the original sender was worried that looking up the salts would let an
attacker test if usernames are valid without knowing the password ]
Anyway, if you do hash on the client side too, you're right that you
really don't want to let an attacker test if usernames are valid. Since
you're still hashing on the server with a random per-user salt, it's OK
to sacrifice randomness for the client-side salts. I recommend combining...
1. The username.
2. A website-specific string (e.g. the domain name).
...to make the client-side salt. It's not guaranteed to be unique (e.g.
domain changes ownership), but it's very likely to be. It's good enough.
Another thing to consider is that not all users have JavaScript enabled
in their browser (I don't), so whatever you do, the system should fall
back to emulating the JavaScript hashing on the server if the user isn't
running scripts in their browser.
-----
I'll add this to the FAQ or to the main article since it's very
important to get right!
Thanks!
havoc
----- End Email Response -----
|
|
|
|
|
Yeah, I had already sent an email to them. It's the one he copy-pasted to you.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Thanks for the feedback. I got a few emails about this so I added a subsection to the page explaining it. It's under the heading 'In a Web Application, always hash on the server' if you want to read it in HTML, but I'll copypaste it here so readers don't need to hunt it down.
Here's what I wrote:
If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?
Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.
The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.
This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:
- Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password.
- Some web browsers don't support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.
- You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password. Since you're hashing and salting (with a good salt) on the server too, it's OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.
|
|
|
|
|
We send the password salted as well as a challenge for logging into our Silverlight app.
|
|
|
|
|
Hold on:
To create : Take a random salt + password and hash. OK I understand.
To validate : Take the random salt + password and hash and check against the stored.
This does not compute... There are 2 random salts here... so 2 different hashes? Unless the salts are stored... and if your system has been pwned, your salt is pwned too.... And so back to square one...
|
|
|
|
|
"And so back to square one..." - Neggative, Salt is not a secret value, it merely serves two purposes:
Purpose a) By forcing the use of a salt, we need to generate a hash table for every available salt to get passwords that are using that salt, driving up the cost of hash table creation (as rather than one table for all passwords, need one table per salt)
Purpose b) By using Salt we ensure that two passwords of the same value have different hash value due to the different salts....this stops things like finding all users with hash 1e0b2ffs7 blah mc blah and tying that hash to a specific password.
i hope I make sense, but if you want a .NET API to do it properly than look no further than here: http://sourceforge.net/projects/pwdtknet/[^]
|
|
|
|
|
Hi,
This I understand. What I mean is this: If each salt is unique, your passwords will never match as between generation and comparison, they will have to be different!
In very simplified pseudocode:
Making the salted password
$salt = generateRandomSalt();
$pwd = md5('password');
writeToDb($salt + $pwd);
Checking the salted password:
$salt = generateRandomSalt();
$pwd = md5('password');
if(($salt + $pwd) == getStoredPasswordFromDB()) then
win();
else
fail();
endif
As the generated salt will always be random, the salt will always be different for each call, so... if both passwords are different, how do you validate it? In this example with a random salt, the checking condition will always fail, and if you store the salt (or even store the method of generating a unique salt per user), then you are pwned just as bad, it will just take some extra time to reverse engineer the login system, and from there, back to some form of rainbow tables once the salt part is understood and removed.
Can someone light my candle here? My area of expertise is PHP along with Classic VB & VBA, so a .NET library is not much use, but really, it's the idea of just how this really works, as I am already sold on the need of such a system!
Cheers!
|
|
|
|
|
G'Day,
Yes you are correct you cannot just generate a new random salt at each authentication. You ONLY generate the random salt when the password is created, and the sal is indeed stored somewhere, generally in the DB with the Hash. Now what you are saying is if the DB is compromised and the attacker gains your hash and your salt you suggest that they are pwned and can then use the salt to generate a hash table. Now you are correct that the salt can be used to generate a hash table however that is why simply salt + hashing is not good enough. You also need to implement key stretching. The point of key stretching as per PBKDF2, Bcrypt etc, is such that generating said hash table takes an INFEASIBLE amount of time. It does this by performing a hash function such as HMACSHA1 over x (supplied) number of times and XORing the result of each pass with the previous one. If each hash generation takes half a second, it would take 1 second to generate two hashes! Making hash table generation not a viable option.
So basically it is fine for the attacker to gain your salt, hell give it to them if they ask for it even....you should always assume your salt is known anyway!!!
So folks always remember salt + password -> Key Stretching Function -> hash output to store.
I think the provided article does a better attempt at explaining than me but I hope I make sense anyhow
Cheers,
Ian
|
|
|
|
|
The personal nature of coding style is a challenge in a team atmosphere. Oftentimes, seeking to avoid lengthy arguments, teams defer creating style guides under the guise of not wanting to “discourage innovation and expression.” Some see team-defined style guides as a way of forcing all developers to be the same. Some developers rebel when presented with style guides, believing that they can’t properly do their job if someone is telling them how to write their code. // Code as I say, not as I do
|
|
|
|
|
Whenever an argument descends into codeing style you can be sure a dozen more important problems are being missed .
|
|
|
|
|
SSH keys are useful to login over ssh (secure shell) without typing a password. They are also used by Github and other version control systems for passwordless authentication. Here is some basic information from the software developer point of view how to use SSH keys for maximum comfort and security. Sudo no more passwords?
|
|
|
|
|
Rob Pike is a software pioneer. His influence is everywhere: Unix, Plan 9 OS, The Unix Programming Environment book, UTF-8, and most recently the Go programming language. He recently gave the closing presentation at Heroku's Waza conference. Check it out. If you look at programming languages today, you might think the world is object oriented. It's not.
|
|
|
|
|
A couple of months ago (before it was even announced), we made the decision to convert all of our Javascript to Typescript. We finally got around to doing it a few weeks ago and this week I was trying to assess what measurable benefits we got for it. The first way I've looked at it is how many bugs did we find in the code that were uncovered just by getting Typescript compiler errors after the conversion. If the premise that large Javascript programs are difficult to get right and hard to validate and Typescript is a good tool for helping write more "correct" Javascript holds, you'd expect to find some bugs in a large code base you migrated. And sure enough, we did... From 80,000 lines of Javascript to a TypeScript-based front end... and fewer bugs.
|
|
|
|
|
TypeScript === 
/ravi
|
|
|
|
|
F# 3.0 is about to be released, bundled in with the new all-grey, ALL-CAPS Visual Studio 2012. The biggest new feature is type providers, bringing some of the benefits of dynamic languages into type safe world. Innovations like type providers deserve more industry attention. I really hope these ideas will spread and hopefully languages like Scala will pick them up pretty soon so more developers (including me) can enjoy the benefits. OK, that's cool, but how is good old F# doing? Well, about the same. It lumbers on in obscurity under the massive shadow of Microsoft and whatever crazy idea the company is currently peddling. How do we save this gem of a language?
|
|
|
|
|
Terrence Dorsey wrote: How do we save this gem of a language?
That's a complicated question. I tried 3 different responses, then realized, that's a complicated question! I'm hoping to write an article on type providers for Oracle (if someone doesn't beat me to it), after I update a certain *cough* article that I promised you guys something like 6 months ago.
Then, people need to see the benefit of F#, and that's not really easy to accomplish. It's a different way of thinking, the OO support is great but that isn't what FP is about, and who needs type providers for DB's anyways given the number of ORMs one can choose from.
It's a good question, and one I struggle with.
[edit]Oh, and at the moment, I disagree with the statement ...F# is superior to C# in every single way, for any application. That's just "jump on the latest tech bandwaggon" blabbering, IMHO.
Marc
|
|
|
|
|
Marc Clifton wrote: F# is superior to C# in every single way, for any application. That's just "jump on the latest tech bandwaggon" blabbering, IMHO.
one position himself ahead of the curve simply by not jumping on every latest bandwagon - focusing on capability instead.
dev
|
|
|
|
|
Marc Clifton wrote: I'm hoping to write an article on type providers for Oracle
Yes please!
|
|
|
|
|
Marc Clifton wrote: It's a different way of thinking, the OO support is great but that isn't what FP is about
I agree, and I see that as a problem. F# is fundamentally a functional language, yet it is bound to a Smalltalk-style object oriented framework with class hierarchies, null references and all that jazz. The result is a little bit like C++ - too many features crammed together and not necessarily well composed.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
