I have read the following article http://lifehacker.com/5919918/how-your-passwords-are-stored-on-the-internet-and-when-your-password-strength-doesnt-matter
There are a number of ways a site can store your password, and some are considerably more secure than others. Here's a quick rundown of the most popular methods, and what they mean for the security of your data.
Method One: Plain Text Passwords
How It Works: The simplest way a site can store your password is in plain text. That means somewhere on a their server, there exists a database with your username and password in it in a human-readable form (that is, if your password is testing123, it is stored in the database as testing123). When you enter your credentials on the site, it checks them against the database to see if they match. This is the worst possible method, in security terms, and most reputable web sites do not store passwords in plain text. If someone hacks this database, everyone's password is immediately compromised.
Does My Strong Password Matter? No way. No matter how long or strong your password may be, if it's stored in plain text and the site gets hacked, your password is easily accessible to anyone, no work required. It still matters in terms of hiding your passwords from, say, your friends, or others that could easily guess it, but it won't make any difference if the site gets hacked.
Method Two: Basic Password Encryption
How It Works: To add more protection to your password than plain text provides, most sites encrypt your password before they store it on their servers. Encryption, for those of you that don't know, uses a special key to turn your password into a random string of text. If a hacker were to get hold of this random string of text, they wouldn't be able to log into your account unless they also had the key, which they could then use to decrypt it.
The problem is, the key is often stored on the very same server that the passwords are, so if the servers get hacked, a hacker doesn't have to do much work to decrypt all the passwords, which means this method is still wildly insecure.
Does My Strong Password Matter? No. Since it's easy to decrypt the password database with a key, your strong password won't make a difference here either. Again: this is in terms of the site getting hacked; if you have a nosy friend or family member rooting through your stuff, a strong password can help keep them from guessing it.
Method Three: Hashed Passwords
How It Works: Hashed is similar to encryption in the sense that it turns your password into a long string of letters and numbers to keep it hidden. However, unlike encryption, hashing is a one way street: If you have the hash, you can't run the algorithm backwards to get the original password. This means a hacker would have to obtain the hashes and then try a number of different password combinations to see which ones worked.
However, there is a downside to this method. While a hacker can't decode a hash back to the original password, they can try many different passwords until one matches the hash they have. Computers can do this very fast, and with the help of something called rainbow tables—which is essentially a list of trillions of different hashes and their matching passwords—they can just look up the hash to see if it's already been discovered. Try typing e38ad214943daad1d64c102faec29de4afe9da3d into Google. You'll quickly find that it's the SHA-1 hash for "password1". For more information on how rainbow tables work, check out this article by coding guru Jeff Atwood on the subject.
Does My Strong Password Matter? In this case, yes. Rainbow tables are made up of passwords that have already been tested against hashes, which means the really weak ones will be cracked very quickly. Their biggest weakness, however, isn't complexity, but length. You're better off using a very long password (like XKCD's famous "correct horse battery staple") rather than a short, complex one (like kj$fsDl#).
Method Four: Hashed Passwords with a Dash of Salt
How It Works: Salting a hash means adding a random string of characters—called a "salt"—to the beginning or end of your password before hashing it. It uses a different salt for each password, and even if the salts are stored on the same servers, it will make it very hard to find those salted hashes in the rainbow tables, since each one is long, complex, and unique. LinkedIn is famous for not using salted hashes, which brought them under a lot of scrutiny after their recent hack—had they used salts, their users would have been safer.
By reading the above article i have the following questions in mind
1.Even if i do not have the password,i still can intercept the message digest......i dont even need the password ...i will simply launch reply attack(ie. send message digest itself for authentication after intercepting it!!)
the solution to above problem can be solved by following way
a.server genrates a random string(usually known as challenge) to the user and asks him to encrypt it with his password .....
b.user enters his password,message digest of the password is created ,random string is encrypted by this message digest
c.this encrypted string is sent to server.
d.server also encrypts random string with message digest of user,checks it with encrypted string recieved from user,if both match,he is valid user..!
2.My question is If the hacker gets access to the database,he will get access to the messagedigests/even if he does not get access to database,he can still obtain message digest while intecepting communication link when user first registers to DB......how this can be prevented??
Even if i do not have the password,i still can intercept the message digest......i dont even need the password ...i will simply launch reply attack(ie. send message digest itself for authentication after intercepting it!!)
This shouldn't be possible.
The client should send the real password to the server. It should be encrypted using SSL.
The server should hash the password and compare it to the stored, hashed password.
the solution to above problem…
That is, more or less, part of what SSL does.
My question is If the hacker gets access to the database,he will get access to the messagedigests
This is a relatively insignificant problem. The passwords should be stored as hashes with varied salts. The original passwords are protected.
even if he does not get access to database,he can still obtain message digest while intecepting communication link when user first registers to DB
Only if SSL is broken.
User registration should always be done through an SSL tunnel, so generally when following best practice you never have to worry about man in the middle type attacks.
Related
I have inherited an app to maintain and I just discovered that when a user logs in, the returned JSON from a successfully login contains:
Primary Key of the User record in the DB
User Name
Encrypted Password
The password's Salt
It seems that having the Salt and Encrypted password voids the purpose of the salt in general.
A brute force or lookup table attack is now available again as a cracking approach.
Am I correct on this, and is there more of a threat than just that?
It's not the greatest but it is generally OK to disclose the salt. You're thinking of a pepper, which is to be kept secret.
The salted hash is not meant to prevent a brute force attack. It is meant to prevent a rainbow attack. By including the salt in the input value to the hashing algorithm, it becomes impossible to precompute lookup tables, unless the hacker creates a lookup table for each and every possible salt.
In my opinion, even when it's not something like giving away a password, you're giving away information that your front-end will not need at all and that could lead to an attacker getting the password! I mean, yes, if an attacker gets that information, he still needs an exhaustive search, with all the possible password combinations concatenated with that salt (or hashing a password dictionary with that salt), but you're giving him resources for an offline attack, and now he can try as much different passwords as he wants until he gets bored, or he gets the real password.
Someone may be thinking that it's the same as an attacker trying to authenticate with different passwords, but the main difference, is that in an online attack, you can limit the number of login attempts, so he'll not be able to try as much as he wants, while in an offline attack, he can try as many passwords as he wants.
All this could be avoided by just sending a boolean, instead of the full object and since it's not like it will require a huge refactory or something like that, I think that it's something that needs to be fixed (and you should also take a look at what he does with that information, in the worst case scenario, he's retrieving the password's hash to store it in a cookie or local storage to keep authenticating the user, or something like that).
If the salt & hash is only available from a POST to the login handler, then the damage here is very limited.
If there is some webmethod (/currentUser/getDetails) that returns the data, then this is a risk should their be any Cross-Site Scripting (XSS) vulnerabilities elsewhere on the site. Any attacker could call this method via the XSS, and then retrieve the hashed password and salt for offline cracking.
Another low risk is if the JSON response does not output anti-caching headers then another user of the same computer may be able to retrieve their password hash.
I am more concerned that the password hashes are in Hash(Password+Salt) format, rather than in a format using a secure algorithm such as bcrypt or pbkdf2.
I have just pressed 'forgot password' on hosting24.com, only to have my password emailed to me in plain text (see image below). I contacted their technical support to question this and they have told me:
We are using Salt encryption on our website, passwords are not stored
in plain text. Please let us know if you have any concerns regarding
the security of your data.
The way I understand it, is that once a password is 'salted' it cannot be reversed back to plain text. I am also very concerned, considering their partner company 000webhosting was victim of a massive hacking incident recently, which exposed that their security was sub-par.
Thanks.
EDIT:
After a few heated emails I finally got this response:
Our passwords are encrypted with a secure encryption method in the
database. Although we do have a decryption method in place (that is
used to prevent fraud), all this is going to change as we are
re-designing the project and updating the code to adhere to new age
standards. We are sorry to have let you down on this one.
Please contact us with any additional questions. Happy holidays!
'New age'. Amazing.
EDIT:
I sent the website this link to prove a point, so I anticipate a load of down votes from their tech support.
Salted hashed passwords are not directly reversible—that's the point of hashing. However one can always try to recover them through brute force, trying all possible/likely passwords to see if the hash matches.
How expensive that is to do depends on the strength of the hash used, but you would never build a system that stores and decrypts passwords that way. If they said they were storing only salted hashes, and still were able to send you the password you originally set yourself, they're clearly lying.
They don't mention hashing though:
We are using Salt encryption on our website, passwords are not stored in plain text.
“Salt encryption” isn't a thing, but let's be as generous here as we can.
It is possible they mean they're using reversible encryption with some randomised element (variable IV, or extra data in the encrypted message) which would ensure two passwords don't get matching encrypted versions (ie the same purpose as the ‘salt’ in a hashing operation).
It's also conceivable that there could be some valid reason why they need reversible passwords, for example if they need to use the passwords to authenticate to another separate system. It's possible to build reasonable systems with reversible passwords, but compared to Good Old Bcrypt it's a whole lot more effort to manage this way (eg keys on the application server; wide-ranging internal policies to manage that; HSMs; and watertight code auditing).
Let's say we accept that this is what they've done and they've implemented it solidly (which is highly doubtful—much more likely they've got plaintext passwords or a hacked-up and vulnerable AES). Even then, they've then blown it by sending you the reversed password in a mail over the unencrypted public SMTP infrastructure.
There are things you can do to mitigate the untrustworthiness of the mail channel, such as sending a single-use token or temporary password that requires a new password to be set afterwards. But there is never a good reason to send an existing password, that will continue to work on the target site and which you might have used to secure other services. User-set passwords should never touch SMTP.
No, they can't without astronomical computing power. I'd bet large sums of money that they have a second database of plaintext passwords.
I have been looking for a good explanation of how to implement a password login system in a typical website environment. I have read some great wikipedia articles and SO Q&A and blogs etc but they always seem to focus on purely generating the hash rather than the whole process of creating hash sending which parts of it, storing which parts of it, what the server side code does with it etc. If there is already a good answer on SO I apologise for reposting, and please link.
My current understanding is:
1) A new user creates a new account on your website. They enter a "password", the client side code then generates and appends a long random string "salt" to the end and generates a hash -> BCrypt(password+salt) for example. The client code then sends the full hash plus the unhashed salt to the server.
2) The server stores the full hash and the unhashed salt in the users entry in a DB.
3) During the user login they type their password which is then hashed with a salt again,
Question 1) How does the client side code generate the same 'random' salt value for each user?
Question 2) at this point does the client side code just send the full hash without the salt?
Question 3) what does the server side do with the full hash once it has received it? (simply compare the sent full hash with the stored full hash? If that's the case then can't an attacker upon breaking into the db and getting the stored full hash values just use them directly to send to the server to log in? This is based on my assumption that the log in process essentially involves the server comparing the full hash sent from the client with the full hash stored in the db.
Question 4) should passwords always be sent over secure connection? or does salting and hashing them make it ok for anyone to see?
You are confusing the purpose of the hashing. It is not intended to secure the password for wire transmission. The client does not generate the hash. the purpose of the hash is to prevent an attacker who compromises your database from being able to quickly use a pre-generated hash lookup table to determine what your user's passwords are.
A trivial example follows- as #jhoyla points out in the comments below, industrial grade production schemes are even more complex.
To create an account:
The client establishes a secure (encrypted, e.g. SSL) connection with the server, and sends the username and password, usually in plaintext (which is OK, because it is encrypted).
The server generates a random salt, appends it to the password, hashes the result, and stores the hash and the unhashed salt value.
To log in:
The client establishes a secure (encrypted, e.g. SSL) connection with the server, and sends the username and password, usually in plaintext (which is OK, because it is encrypted).
The server retrieves the salt from storage, appends it to the password, hashes it, and compares the result to the hashed password in storage. If they match, the user is logged in.
To establish why we do this, imagine that I have successfully attacked a website's database server and downloaded the database. I now have a list of usernames, probably email addresses, and password hashes. If the passwords are not salted, then there is a very high probability that many of the hashes will be the same (because many people use the same weak passwords). I know that the likelihood of one of those users having that same weak password on (for example) their email account is quite high. So I go to work and hash the whole dictionary, plus many other likely passwords, looking for a hash that matches one of these popular ones. If I get a hit, I've just broken a bunch of passwords. If I was smart, I'd have generated this list in advance so that I can do it quickly.
Now imagine that the passwords are salted. Now, even if two people use the same password, a different salt will have been generated for each of them, and the resulting hashes will be different. I have no way of knowing which passwords are weak, common passwords, and which ones are strong passwords. I can try my dictionary attack by appending the salt to each possible password, but the difficulty (in terms of time) of cracking a password has now gone up exponentially.
never ever implement it yourself! if you need it just for learning then #Chris answered you. but if you need for for a working software then don't do it. every language has security libraries and every data store (ldap, database) has password storing mechanism already implemented. use it, don't invent the wheel again because you will most probably miss some detail
I am new to web development. Am I allowed to store users' original passwords? I know good practice is to store the hashed password using a salt, but why don't we store the original password?
Is it because the database is easily hacked, so hashing protects passwords? Are there any other reasons? If not, I would like to store the original password if it is legal to do so.
The legality depends on the country you live in. But there are best practices, too. And a best practice is to encrypt user's passwords. In this way, if someone breaks into your database, they will not be able to obtain the long list of passwords, and try each one of them in ebay, yahoo mail, and gmail. Users generally use the very same pair of username and passwords for many sites.
As Jon points in the comment, of course there is difference between hashing and encrypting. Hashing is a one-way, data-destructive process, which takes an arbitrary-length string as input, and outputs a fixed-length string. This string is defined in such a way, that changing any single bit in the original input, will cause the hash to be different. If you have a hash, therefore, it is not possible to reconstruct the original text (i.e. it is not possible to recover the password).
On the other hand, encryption proper is a technique where you can recover the original password, knowing secret keys, passwords, etc.
Usually, you want to hash passwords, not encrypt them: it's not necessary, and it is more complex to setup. You are not supposed to recover password either: you will just regenerate them.
Imagine if Facebook was hacked, it didnt encrypt any of the user's passwords. Facebook itself has around 200 millions(?) users
What if all of the 200 million passwords were leaked to some evil organization? Many users use same password as their mails or any other sensitive online services such as bank accounting.
Facebook wouldn't be safe at all once. Would you register an account there?
I don't know if it's legal, but nonetheless I would advise against it for at least three reasons:
This is not only about hackers getting access to your passwords. Users often have the same password for multiple accounts (also they shouldn't have). So who says we can trust you or other people who have legal access to this data?
It doesn't matter how secure you think your server is. There is no such thing as absolut security for a server. You should consider that it could be hacked eventually. And don't believe it'll never happen. Hope for the best, but always plan for the worst!
I would use every easy and cheap security I can get to secure not only my data, but also the data of the users. And the method of using a salt+hash is cheap. It will cost you 2 lines of Code. It
Yes, it's perfectly legal, though absolutely not recommended to store passwords in plaintext. And it's not that your actual live database can be compromised: even a backup copy can be stolen (without you ever knowing it).
When passwords are stolen, this is very bad for your actual users, since very few of them actually use different passwords for different sites.
It is legal according to the law. Some companies store the password in plain text, so that it is recoverable.
However, for safety reasons this is a bad idea. Once in a while, some company gets hacked and their database is accessed. In some cases, this exposes the passwords of thousands of users. This will severely damage the image of your company, and is even more a security risk when the password is not hashed.
If you want the password to be recoverable, at least encrypt it so that it is not easily viewable by accessing the database.
The original password isn't stored because once the database has been hacked your vulnerable information is at risk including your password so encrypting will not do anything once they have access through other sources. Depending on where you live some sites will store your password in plain text, For example, if your password is Appletree1234 they will stored your password in plain text as Appletree1234. According to Lifehacker.com, when you enter your credentials on the site, it checks them against the database to see if they match.
Situation 1 - Connecting the server to the database:
Its always said that passwords should not be stored in plain text, however to connect to the mysql database requires the password, in plain text it seems... I'm guessing the best solution to this is to store it in an encrypted form, decrypt it in my app as needed and then erase it from memory (SecureZeroMemory in windows I guess so the compiler cant optimise it out).
Situation 2 - Users logging into the server from a remote computer:
As for users passwords my plan is to never actually store the original password at all.
Instead I will store a randomly generated "salt", for each user, prefix there password with it then hash it, which seems to be a relatively common way. However I don't have an SSL connection available at this point, so I'm guessing the plain text passwords could be intercepted, what's a good solution to this?
What are good algorithms (links to C/C++ implementations would be handy as well if you have them) for doing this, a look on the net comes up with 100's of them?
EDIT:
If I got SSL, would the following be secure (assuming a strong hash algorithm is used), or should a different method be used?
Client requests salt for a user name
Client prefixes password with salt, then hashes it before sending the hash to the server
Server compares hash recieved to the one on the server for that user name
Connecting the server to the database
Just storing the database password in the server - encrypted or not - is a bad idea. It is obvious storing it in plain text, of course. And if you just store it encrypted, the server still needs the key to decode it. It is usually not very hard to find the key in the server code. The best solution is to let the user starting the server enter the password and store it nowhere. Alternatively - and probably even better - you can store all sensitive information - for example database users, passwords, and so on - encrypted and let the user starting the server enter a master key to decrypt this information.
Connecting a user to the server
This is really a hard problem and easy to mess up. A quote from this great article article on the topic I absolutely recommend reading.
No, really. Use someone else’s password system. Don’t build your own.
A good solution might be using the Secure Remote Password Protocol.
You are correct that if you're not using SSL then the passwords can be intercepted.
It is common practice to never decrypt a user's password, so keep it stored hashed with a salt and when the user types in their password you will add the salt and hash it, comparing it with the stored, hashed password. This will allow you to never have the decrypted version of the password every.
You really should look into securing the connection so that the password is secure when the user types it in.
Update to answer edited question:
If you have the communication secured using SSL you can still use any number of extra measures of security you like including hashing the password. As added security it is a good idea to remember that the password you store should be stored hashed with a salt. That salt should be kept safe and never be accessible anywhere except by your application. This way when the user submits the password you just add the salt and hash and you compare that version with the stored version.
Situation 1 - Connecting the server to the database
There isn't an easy answer here. In order to connect, the server needs the password (or symmetric key, or private key or whatever). It must get it either from the disk or some external means (like an administrator typing it at startup). Adding some indirection, such as encrypting all the sensitive stuff under a master password, can add some convenience but otherwise doesn't change the situation.
Typically, it is fine to put the password or key in a file on a server. If you do this, make sure to set the permissions on the file so that only the users that need it have access to it. This is an excellent reason to have different processes on your system run as different users, and to set up separate roles/accounts and passwords for each.
Situation 2 - Users logging into the server from a remote computer
You are headed in the right direction here, I think. What it sounds like you're asking for is a secure authentication protocol. You want one that provides mutual authentication and prevents a man-in-the-middle attack by failing if such an attack is attempted. There are many to choose from of course.
It is also worth mulling whether your authentication should operate based on "something you know" (passwords) or "something you have" (public/private keys). Assuming based on your question that what we're looking for is passwords, two that I like are SRP and Kerberos.
SRP was mentioned earlier, and that doesn't get nearly the attention it deserves. SRP has the advantage that it doesn't require the server to know the password, or key, or anything that an attacker could use to gain access. If you broke into a correctly configured server using SRP and stole all the data, you'd still need to do something like a dictionary attack on each key individually before you had anything you could use to impersonate a user.
I also like Kerberos because it is supported by tons of software (I know Postgres supports it, I've only found mentions of mysql not supporting any good authentication technology) and has a system of 'tickets' that provides a single sign on capability. Kerberos needs some other technology to help strengthen its initial authentication exchange and SRP would be great for that but I'm not sure they've done that yet. Something about it making the KDC (key server) stateful I think.
Kerberos' weakness is that you have to be more wary of the server storing the keys. While it doesn't store the passwords in plaintext, it does store the keys, which are essentially hashed versions of the passwords. And while the client doesn't exactly send either the password or the key straight over when authenticating (this is a Real auth protocol after all), it does use the hashed password as the key, and so anyone else who knows the algorithm and knows the key could do the same. We say that the server stores a "password equivalent". As a result, all the manuals tell administrators to put the kerberos services on their own separate, locked-down boxes to minimize the chance of compromising their contents.
The nice thing is, once you settle on a strong authentication exchange, other good things typically fall out of it for free. You end up with both parties sharing a mutual 'secret' that can be used once for the duration of the session, never sent over the wire, and can't be known by a third party. Want encryption? There's the key, all ready to go. This is exactly how SRP-secured SSL is defined in RFC 5054.
Not sure if this is what you are asking for.
But a simple PHP example using the built in sha1 function:
// Check the hashed password from the database
if (sha1($salt.$password) == $providedPassword)
{
// User is authenticated
return TRUE;
}
else
{
// User is not authenticated
return FALSE;
}
One thing you could do is also hash the password with javascript before it is sent over the wire. The question is how is the salt string shared between client and server? One possibility is to use a session variable. And then use the session variable to unhash the password afterwards on the server. This would mean that the man in the middle would need to know one other piece of info to make sense of the password. Not as secure as SSL, but perhaps an extra layer of defense against casual network sniffers.
I could also imagine a hashing scheme linked to some sort of captcha system used to salt the password on the local client before sending over the wire. The client would be providing the text for the salt string by completing the captcha. You could look it up on your end.
The main concern is the man in the middle not understanding the plain text password.
SSL should be used, but the above techniques might be useful where SSL is not possible.
Newer MySQL uses hashed password over the wire, so you don't have to worry about man-in-the-middle.
If you worry about the password stored in your configuration file, you can encrypt the configuration file with a password. However, the problem is that you have to enter a password to start your application.
I wrote a similar application over 15 years ago. Back then, PGP was my choice. I am not even sure it's still around.