I've been trying to research authentication systems to model my own project around, but I feel like I'm misunderstanding something significant.
There is a lot of talk about using a per-user salt to hash the password, and this makes sense as a defence mechanism. But almost all info I see about this is done on the server side (back end). This implies that the front end is sending the password as plaintext, which I thought was a no-no.
Then I see discussion of salting the password at the front end (client-side before sending the login to the backend for authentication). This seems to solve the problem of sending the password in plaintext, but introduces the problem that the password must be hashed with the same salt each time in order to match the hashed password stored in the back end. This implies either a site-wide salt, or that the front end is getting access to the user salt.
The latter seemed feasible for a second, but this seems the same as publishing the per-user salt, as the front end needs to access the salt prior to authentication.
Can anyone tell me what I am not understanding?
Salting the password, before it is hashed and saved to the DB, is meant for better protection of the saved password. If someone manages to steal your password DB, when passwords are salted, it will be much harder for them to reverse the hash and get the raw password value.
This has nothing to do with the security of passwords on the front channel. You can send passwords in plain text from your front channel to the backend if you use TLS. The request is encrypted and thus protected from eavesdroppers. You will still be vulnerable if you have a man-in-the-browser or an XSS attack, as the attacker will have access to the plain-text password before TLS encryption is applied. However, hashing the password in the frontend app will most probably not protect you from these attacks anyway.
To sum up:
You can send plain-text passwords from your front end, just make sure to use TLS.
On the back end, make sure to salt and hash passwords before saving them in the DB.
Related
I want to make a user login system for the purpose of learning. I have several questions.
I did some research and found that the proper way of implementing a user login system is to store the user name/id and the encrypted/hashed version of the password in the database. When a user logs in, the password is encrypted client side (MD5, SHA-1 etc.) and sent to the server where it is compared with the one in database. If they match, the user log in successfully.
This implementation prevents DBAs or programmers seeing the cleartext of the password in the database. It can also prevent hackers intercepting the real password in transit.
Here is where I'm confused:
What if the hackers know the hash/encrypted version of password (by hacking the database) or DBAs, programmers get the hashed version of the password by just simply reading the text in the database. They could then easily make a program that sends this hashed version of the password to the server allowing them to successfully log in. If they can do that, encrypting the password doesn't seem very useful. I think I misunderstanding something here.
Is this (the way I described above) the most popular way to implement user login functionality? Does it follow current best practices? Do I have to do everything manually or does some database have the built-in ability to do the same thing? Is there a most common way/method of doing this for a website or a web app? If so, please provide me with details.
My former company used couchDB to store user login info including passwords. They did not do too much with the encryption side of things. They said couchDB will automatically encrypt the password and store it in the documents. I am not sure if this is a safe way. If so, then it is pretty convenient for programmers because it saves lots of work.
Is this way (point 3) secure enough for normal use? Do other database system such as mySQL have this kind of ability that can do the same thing? If so, does it mean that using mySQL built-in method is secure enough?
I am not looking for a very super secure way of implementing user login functionality. I am rather looking for a way that is popular, easy-to-implement, proper, secure enough for most web applications. Please give me some advice. Details provided will be really appreciated.
When a user login, client side code will encrypt the password by MD5 or SHA-1 or something like that, and then send this encrypted password to server side and then compare it with the one in database. If they are matched, the user log in successfully.
No, no, the client needs to send the unhashed password over. If you hash the password on the client side then that hash is effectively the password. This would nullify the security of the cryptographic hashing. The hashing has to be done on the server side.
To secure the plaintext password in transit it needs to be sent over a secure channel, such as an encrypted TLS (SSL) connection.
Passwords should be salted with a piece of extra data that is different for each account. Salting inhibits rainbow table attacks by eliminating the direct correlation between plaintext and hash. Salts do not need to be secret, nor do they need to be extremely large. Even 4 random bytes of salt will increase the complexity of a rainbow table attack by a factor of 4 billion.
The industry gold standard right now is Bcrypt. In addition to salting, bcrypt adds further security by designing in a slowdown factor.
Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.... Cryptotheoretically, this is no stronger than the standard Blowfish key schedule, but the number of rekeying rounds is configurable; this process can therefore be made arbitrarily slow, which helps deter brute-force attacks upon the hash or salt.
A few clarifications:
Don't use MD5. It's considered broken. Use SHA but I'd recommend something a little better than SHA1. - https://en.wikipedia.org/wiki/MD5
You don't mention anything about salting the password. This is essential to protect against Rainbow tables. - https://en.wikipedia.org/wiki/Rainbow_tables
The idea of salting/hashing passwords isn't really to protect your own application. It's because most users have a few passwords that they use for a multitude of sites. Hashing/salting prevents anyone who gains access to your database from learning what these passwords are and using them to log into their banking application or something similar. Once someone gains direct access to the database your application's security has already been fully compromised. - http://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/
Don't use the database's built in security to handle your logins. It's hacky and gives them way more application access than they should have. Use a table.
You don't mention anything about SSL. Even a well designed authentication system is useless if the passwords are sent across the wire in plain text. There are other approaches like Challenge/Response but unfortunately the password still has to be sent in plain text to the server when the user registers or changes their password. SSL is the best way to prevent this.
I want to have a secure login process where login data are encrypted.
Prevent replay attack of the login form.
At the same time, I want the password being encrypted and no one can decrypt them.
For 1. I can MD5 the form data.
For 2. I can generate a nonce and hash it together with client password.
For 3. I can use salt stored in DB and save only MD5(password|salt) in DB
Now the problem comes, for 1 and 2, I will be sending MD5(password|nonce) to server, but I am unable to authorize it because I don't have the original password for checking.
Can I archieve 1,2,3 at the same time?
For 1. and 2. Use HTTPS (SSL). It prevents active and passive attacks, replays, keeps the password confidential.
For 3 use a specialized password hash together with a per-user salt. Standard choices are scrypt, bcrypt and PBKDF2. Do a bit of research for the details, we have plenty of related questions here and on security. SE.
For transport security use SSL/TLS.
For replay protection use CSRF Tokens.
For secure password storage use keyed hash something like this.
Edit: Presented scheme is not insecure, you can read more about this idea in this post at security.se
I am trying to create a login system for a web application, but I am stuck on a couple of points. I am storing the password in my database using a sha2-512 hash with a 128 bit random salt.
However I currently have the password posted in plain text to my application using a html form, both when the account is created and when the user logs in. I know this is wrong.
Do I need to hash the password in the client? If so how do I take into account the salt which is currently generated and stored on the database?
NOTE: I am doing this to learn not to use in a production system
The best bet is generally just to use SSL. If you did need to hash on the client side, this is how I'd do it:
When you first store the password, hash the password with a stored salt as is commonly done.
When someone needs to login, send them the stored salt, along with a second, randomly generated salt.
The client will hash the plaintext password with the stored salt, then the random salt and send the hash to the server.
The server will hash the stored password with the random used in that request salt and compare.
This is secure because it ensures that the hash being transmitted is unique to the request (it uses a single-request random salt), so a login cannot be faked in the future simply by sending the hash again. It is not dangerous to send the client their stored salt, as it is assumed that password crackers will have access to the stored salt (if they get access to the db). Two hashes are required to prevent you from ever having to store the password as plaintext.
You should be using SSL to transmit the passwords encrypted so that a man-in-the-middle can't intercept the packets and read off what ever credential is being sent. Even if you pre-hash the password in the client, a man-in-the-middle can still just use that value to fake identity.
What really concerns me, though, is the use of SHA-512. A lot of people use cryptographic hashes for password storage, but popular opinion misses a very important point: These hashes were designed to be fast. That is, one of the requirements to become an SHA (or similar) hash is to be able to quickly hash large documents on embedded hardware.
This is the exact opposite of what you want for password storage, as it allows specialized routines on high performance GPUs to brute force passwords at a surprising and scary speed!
This is why some purpose built password storage hashes have been developed. The one I have been using is Bcrypt, which is slow enough to keep out brute force attacks, adjustable to couneract faster hardware in the future, and has the added bonus of handling the salting for you.
Hashing the password on the client would require the use of the salt on the client. This also exposes your algorithm for very easy hacking on the client side. The best thing to do is to perform this action over SSL (HTTPS) so that the entire transaction is encrypted and the authentication only happens on the server.
I.e.: Your user ID and password are transmitted encrypted from the client. The web server decrypts the data and passes it to your server-side authentication function where you look up the user and associated salt, perform password + salt + hash and compare it to the stored hash for a match. This means that the hash and then salt never need to be transmitted from the server at all.
You really need to be using SSL on any page where you are transmitting passwords. If you try to encrypt them on the client side it will be in javascript and very easily reverse-engineerable.
I'm trying to secure a website that is being moved to a public server soon. I've just finished adding the password hashing functions to all of my login scripts. I'm using FormsAuthentication.HashPasswordForStoringInConfigFile(pw, method) to do so. I have a question about the process I'm using and whether or not it's secure for a web server:
Password is sent in plain text over HTTPS to the server
The server looks in the Users table to find the user's Salt (several random characters) and their hashed and salted stored password
The plain text password is appended with the Salt
The new string is hashed using the above function
The newly hashed version is compared to the stored version
If equal, login is allowed
If not equal, the login attempt is logged in Session variables, up to 3 times before locking out the user's machine from accessing the login page until an admin verifies IP address and unlocks.
Does this look about right? I just don't see how the salt is effective in this method... Anyway, all I've done is add a salt and hash. Is this considered Encryption? Or am I missing a step? I remember reading that hashing algorithms like SHA1 and MD5 are not encyption algorithms, so what else needs to be done?
That is correct. The salt is used to prevent rainbow table attacks where a dictionary of common works hashed with MD5 is used to try to gain entry. Using the salt ensures that even if they had an MD5 hash of the word, it wouldn't work because they don't know the salt.
The MD5 algorithm is a 1 way hash algorithm, and not an encryption value. The difference is, once you've hashed the value, there is no way to get back to the original value. Encryption allows you to decrypt the data and get back the original value. So you are correct, they are not the same, and your passwords are not encrypted, they are hashed. This means that if someone forgets their password, you cannot send it to them. You have to provide a way for them to reset their password instead. This also means that anyone with access to the database would not have access to raw passwords. Which is good because a lot of people use the same password everywhere, and if you had access to a large list of usernames and passwords, someone could decide to start trying to log into bank / credit card websites.
What you are doing is a recommended practice.
You shouldn't be storing the retry count in the session - an attacker could simply discard their session cookie after each attempt, allowing them to retry as many times as they wish. Instead, store it against the user record.
When sending passwords via UTF-8 encoded socket transfer, is it considered to be secure if I hash the password using either MD5 or SHA-1 prior to sending out the data? Keep in mind that I plan to compare the hashed password in a SQL database. I am worried that someone could be able to sniff the hashed password in UTF-8 then decrypt the UTF-8 encoding and could obtain my hashed password which could potentially be used to match the password in my database.
If the client just sends the hashed password, then the hashed password is the "password": a sequence of bytes which the client just needs to show to be authenticated. If the attacker can sniff that then your protocol is doomed.
If the authentication protocol consists in just presenting a piece of secret data (call it a password if you wish), then the exchange should occur within a transport medium which ensures confidentiality (so that the secret data cannot be sniffed) and server authentication (so that an attacker may not mimic a server and convince a client to send him the secret data). This is what you get out of a classic SSL/TLS tunnel (a https:// URL, in a Web context).
If you cannot establish a SSL/TLS tunnel with server authentication (i.e. the server has a certificate which the client can verify), then you may want to resort to an authentication protocol with a challenge: the server sends a sequence of random bytes (the challenge) and the client responds with a hash value computed over the concatenation of the password and the challenge. Do not try this at home! It is very difficult to do it right, especially when the attacker can intercept communications (active attacks).
A more generic answer is password-authenticated key exchange protocols. PAKE combines a cryptographic key agreement protocol (such as Diffie-Hellman) and mutual password authentication between client and server, in a way which defeats both passive and active attackers, even with relatively weak passwords (the attacker cannot get enough data to "try" passwords without interacting with either the client or the server for each guess). Unfortunately, few PAKE algorithms have been standardized beyond mathematical description, and the area is a patent minefield.
Well, if someone can sniff hash - he can fake authorization request and send the hash he already know.
Making up secure system is not easy, you would need to do authorization using asymmetric cryptography with properly signed keys to make it secure.
At least add ~100byte random salt, and use SHA1 - this way it would be way harder to bruteforce.
They could brute-force your passwords if they know the hashing algorithm. The simple (and not perfectly secure) solution is to use a challenge/response instead, the server issues a random string ("nonce") to be hashed along with the password hash. This makes your app invulnerable to the kind of replay attacks you're describing.
For more information, see HTTP's digest access authentication
Hm, if you are talking about 'proper' hashing, that means that it will 'encrypt' your password so it won't be decrypt-able, because hashing is one way function, and to decrypt it - it till take some time, and some kind of great CPU power.
If you are concerned at password sniffers, you can take it to the next level - use PRIVATE/PUBLIC key encryption. Server should send a challenge to the client (public key for encryption), client encrypts with it, and only server know how to decrypt it. For same amount of bits, it offers more protection - ie. more muscle is needed to brute force crack it.
Check this out.
How do you check the password on the database side?
If you store the unsalted hash of the password and just compare it to the input, then the hashed password can be sniffed and reused.
It's exactly as if you were storing the password itself in the database in plain text.
If you are afraid of sniffing, use a challenge-response protocol to authenticate, but in this case the secret will be stored in the database (and will be known to anyone who has access to the database).
Alternatively, you can send a password in plain text over a protected channel (SSL), but you will have to install a certificate which will most probably cost you some money (if you are using an authority from a vendor-provided list, i. e. one your customers' browsers won't complain about)