I'm working on a user authentication thing for a web site.
Having read the book Innocent Code, I have followed its advice for storing passwords as hash(username+password+salt). The theory being that hashing the password alone is not secure (subject to dictionary/rainbow table attacks, and potentially not a unique hash on any given site if more than one user uses the same password). Hashing the username and password together should be unique on any given site, but users may repeat these same credentials on different sites, so if it does get cracked on one, it could get cracked on many sites. So use a hash of username, password and a site specific salt value should make a globally unique hash (subject to the limitations of the hash algorithm itself)
I currently have two tables in the database: Users and Passwords.
The users table stores the user name and related information about that user (permissions, preferences, etc) but does not contain the password.
The passwords table is a single column table storing the hash of the password as described above. The hash is it's own primary key on that table. I've made the assumption that hashes should be sufficiently unique that I'm not ever likely to end up with duplicate hashes and therefore duplicate keys (Please correct me if I'm wrong in that assumption.) Authentication is done by recreating the hash from the user name and password supplied by the user (plus the secret salt) and checking if that hash exists in the db. If it's in there, they authenticate.
So far, this is working nicely.
Using this scheme, there should be no way to associate a password hash with any particular user. Knowing the user id won't help anyone find the corresponding password hash.
I'm not sure how I came up with this scheme. I thought I'd read it in the Innocent Code book, but I just read it again and it only goes to as far as hashing the passwords with a salt. It doesn't appear to suggest separating the passwords out of the user table.
Now my problem is that if I ever have to delete a user from the system, I have no way of knowing which password was associated with that account, so I can't delete any passwords. I can see ending up with orphan password hashes in the passwords table in the future.
So my question is: how should I be dealing with this?
Am I being paranoid by keeping the passwords separate from the users table? Creating a bigger problem for myself than I am solving? Would it really hurt to put the hashed passwords in the user table? Would it be better to have a single table dealing with all user information?
Yes, I think you're being paranoid, creating a bigger problem than you're solving, and that you should just put the hashed passwords in the user table.
If someone's dedicated enough to crack your username + password + salt, they're far more likely to just bribe someone at your hosting facility, an employee, or whatnot. If you're not VISA, this level of security is probably overkill.
I don't think it would be a problem to put the passwords in the users table, seeing as you've already hashed them in a way that would make it very, very hard discover their original state.
Also keep in mind that the amount of work you put into securing the passwords should be somewhat in line with the other safety measures you have on the site. E.g., if the users send their password over a non-SSL connection, it wouldn't make much sense to put the passwords in their own table, etc., since crackers may be able to discover users' passwords just by listening in on the connection.
It should be safe to store the hashed password with the user (you can also have random salts for each user too so the same salt isn't used for each password). If a hacker gets a hold of your database, if the password is hashed, it shouldn't matter if it's associated with a particular user (if you're really paranoid about it, you could always hash the user name too).
Let's assume your scheme is reasonable. If you orphan a password hash, and if your salt never changes, then you have to prohibit any future use of once-active usernames to prevent former users from getting into their namesakes' accounts. Any way you look like it, that's not likely to make you any friends. (At least not me; I dislike sites that won't let me re-register with my own name if long ago I had an account. I dislike even more sites that let someone else into my account...)
There's probably no "right" answer, but think about using something variable as part of the salt. For example, what if the salt were the hash of a user's account creation timestamp, itself salted with a value that you can calculate from that timestamp? Someone would have to figure out both your scheme for hashing passwords and the scheme for hashing timestamps, and the scheme for generating timestamp-hashing salt before the association of a user name to a password hash would be likely to compromise anything.
Then you could much more safely store the password+hashed-variably-salted-timestamp values in the users table.
The database is private (no public access)?
You are sure you don't have any SQL injection potential issue?
Your salt and hash key is protected?
What would be the effect of having a security breach that allow access to the database tables and password hash? (at that point, the rest of the data will be my biggest concern...)
I don't think it worth the trouble to have the password hash in a separate table.
Related
I am developing my first web app that requires a login, and it has come to the point when i must decide how to store the passwords. I have been doing a lot of reading on the proper way to hash the password and adding a salt. It occurred to me that most of the ways that are recommended would rely on some variation of information that is stored in the database with the password hash, be it some variation of using all or part of the username as a salt or some other random value.
Instead I was thinking of using the user own password as a salt on the password. Using an algorithm to jumble the password and adding it to itself in some way as the salt. Of course this to would be compromised if an attacker got access to both the stored hashes and the source code of the algorithm, but any salt would be compromised in such a situation. My application really probably does not need this level of security, but it was just something that i started to think about when reading.
I just wanted to get some feedback from some more experienced developers. Any feedback is appreciated.
If you derrive the salt from the password itself, you will loose the whole benefit of salting. You can then build a single rainbow-table to get all passwords, and equal passwords will result in equal hash-values.
The main reason to use a salt is, that an attacker cannot build one single rainbow-table, and get all the passwords stored in your database. That's why you should add a random unique salt for each password, then an attacker would have to build a rainbow table for each password separately. Building a rainbow-table for a single password makes no sense, because brute forcing is faster (why not just stop when the password was found).
Don't be afraid to do it right, often the programing environments have support to create safe hashes and will handle salting for your (e.g. password_hash() for PHP). The salt is often combined with the hash for storing, that makes it easy to store it in a single database field.
I wrote a small tutorial about securely storing passwords, maybe you want to have a look at it.
Simply duplicating the password may still be vulnerable to dictionary attacks, e.g. the password "hello" becomes "hellohello", and thus might be part of a dictionary.
Using a scrambled password as the salt enables the attacker to use a dictionary and then generate a rainbow table for all entries by adding the scambled password on every entry.
Why change a proven algorithm which can be understood by any developer? Just do it the default way and your code will be maintainable by anyone else.
"My application really probably does not need this level of security" - until that point in time it was hacked. Use a salt, it takes almost no additional effort. Do it now.
"eliminate the need of storing the password salt at all": the salt can be very small (6 bytes). It will hardly affect performance.
I just wanted to get some feedback from some more experienced developers. Any feedback is appreciated.
John Steven of OWASP performed an analysis, including threat modes, for password storage system. It explains the components and their purpose, like the hash, the iteration count, the salt, the HMACs, the HSMs, etc. See the Secure Password Storage Cheat Sheet and Secure Password Storage paper.
Cracking is not the only threat here. More than likely, the guy trying to break into your organization is going to be using one of the top passwords from the millions of passwords gathered from the Adobe breach, the LinkedIn breach, the Last.fm breach, the eHarmony breach, the <favorite here> breach.... For example:
25 most-used passwords revealed: Is yours one of them?
The 30 Most Popular Passwords Stolen From LinkedIn
Top 100 Adobe Passwords with Count
Why bother brute forcing when you have a list of thousands of top rated passwords to use?
So your FIRST best defense is to use a word list that filters a user's bad password choices. That is, don't allow user's to pick weak or known passwords in the first place.
If someone gets away with your password database, then he or she is going to use those same password lists to try and guess your user's passwords. He or she is probably not even going to bother brute forcing because he or she will have recovered so many passwords using a password list.
As I understand it, these word lists are quite small when implemented as a Bloom Filter. They are only KB in size even though there are millions of passwords. See Peter Gutmann's Engineering Security for an in depth discussion.
In the official documentation of the PKCS5 V2.0 standard, we can read "The salt can be viewed as an index into a large set of keys derived from the password, and need not be kept secret."
The part "need not be kept secret" is interesting.
Since the salt is used to add a huge range of password possibilities (or to create two different keys if two users had the same password), what is the purpose of letting the salt insecure?
I understand that typically, an attacker wont have access to the salt, so it will complicates his job to find the right password. But if an attacker knows the salt, where is the "magic"? Knowing the salt is like perform a traditional dictionary attack (if we exclude the iteration count)!
Is there something that I dont understand? I know that knowing the salt dont break the security but, saying that it "need not be kept secret" sounds strange to me.
The rest of the paragraph (in the standard) seems to explain it:
... Although it may be possible for an
opponent to construct a table of
possible passwords (a so-called
“dictionary attack”), constructing a
table of possible keys will be
difficult, since there will be many
possible keys for each password. An
opponent will thus be limited to
searching through passwords separately
for each salt.
The point is that you can't just take a list of passwords (let's say 77 million passwords) and run them through the same tables. You will need to build a separate table for each password + salt.
i have to create a login module (The question is not language specific) but i am not sure how will i validate the user. Where and how will i store the passwords. Will i have to encrypt and decrypt my passwords and if yes what are the best suggested way to do them. Overall i need to know what all things i need to take care of for developing a login module where a user can login securely to access my site.
You don't need to decrypt your passwords in order to validate them, just one way encryption works fine for this. The idea is that when a user enters a password, you encrypt it the same way (using the same algorithm and "salt") and then compare with the encrypted one stored in your database. If they are equal, with a great probability it means it's the same original password. Thus you prevent anyone - the adminstrator or any attacker - from knowing the original passwords users use on your web site.
As for the rest, it's very simple, you have a table in your database which contains user logins, encrypted passwords, and possibly some profile information as well (full name, etc).
I usually use the following function to hash user passwords:
$password_hash = sha1(MY_SALT_1 . $login_name . MY_SALT_2 .
$password . MY_SALT_3);
where MY_SALT_* are arbitrary predefined strings, could be e.g. 'the dark', 'side of', 'the moon' (or actually the less related - the better).
Yes.Sure you need to encrypt users passwords.Because most of the users using the same password almost all sites.At that time they are not want to show the passwords to admin.And another reason is most of the time the site DB may be accessed not only by admin.Some other technical persons in the organization.So it is better to encrypt the password.SHA1 is the best way to make the encryption.
Where and how will i store the passwords.
I am not sure what you mean by this.Every one use the database for it like phpmyadmin.
Is it any safer to create a table holding user information and another one for their passwords than using the same table for everything?
No I would just do this:
id, username, password.
Where id is just autoincrement, username is a varchar of 20 (or so, depending on your needs) and password is an MD5 or SHA1 hashed password with a salt.
Using two tables for this just doesn't make sense. Then you need to work with joins to get the data. And that's just an unnecessary burden.
No, I cannot see how that can make it safer.
You should actually refrain from storing passwords at all. Just store their salted hash.
Further reading:
Stack Overflow: Preferred Method of Storing Passwords In Database
I disagree with other people - put the authentication information in a separate table and to the greatest extent possible pull authentication out of your application entirely. You shouldn't care. Think siteminder and the like - your web application doesn't have any information about how the user is authenticated. Password, smart card, etc. (Same thing with Kerberos or Active Directory on desktop applications.)
This approach even works if you use a framework like Spring Security. Just set up your interceptor so it looks at the authentication tables alone. You could even use separate DataSources so your interceptor can't see application data or vice versa.
Obviously your application will still need to manage information about the user's authorizations, something usually handled in a 'roles' table. But there's no need to for it to know how the user was authenticated.
i think having the username and password in the same table is ok ,
but also l have seen people doing silly stuff especially when working with the ORM , someone might end up exposing password hashes etc
for example entity framework C#
someone can just do
appcontext.Users.ToList();
no attributes kept ensuring that password is hidden nor DTOs (Data Transfer Object) ,
upon noticing this l just keep another authentication table and the other thing l there are a lot of fields for forgot password, last password change all those fields l will have them in another table with the password
No it is not safer. Just make sure your passwords are Salted+Hashed before you stored them in the DB.
No. Not unless each table required a different user account to access it - which would make querying it a complete pain - and even then, the hacker has worked out one login, so chances are they can get the other.
Just make sure that you are storing passwords in a hashed form, using a secure hash like SHA-2 and a salt. Do not store them in plain text and (IMHO) don't store them encrypted.
Btw, there is already a pretty simple (and powerful) c# salted hash class library (they've also included a small demonstration of how to use the library) out there - Link .
It also provides a verification mechanism (so you can verify the user's input as a valid password) and you can choose the Hash algorithm yourself (Sha1/MD5/etc.)
There is no security benefit, but using multiple tables can be useful for storing credentials to multiple systems tied to a single login.
As mentioned above, security should be provided by salted hash for passwords.
Here's the situation - its a bit different from the other database/password questions on StackOverflow.com
I've got two sets of users. One are the "primary" users. The others are the "secondary" users. Every one has a login/password to my site (say mysite.com - that isn't important).
Background: Primary users have access to a third site (say www.something.com/PrimaryUser1). Every secondary user "belongs" to a primary user and wants access to a subpart of that other site (say www.something.com/PrimaryUser1/SecondaryUser1).
At mysite.com, the primary users have to provide their credentials to me which they use to access www.something.com/PrimaryUser1, and they specify which "subparts" the secondary users of their choice get get access to.
Mysite.com helps manage the sub-access of the secondary users to the primary user's site. The secondary users can't "see" their primary user's password, but through my site, they can access the "subparts" of the other site - but ONLY to their restricted subpart.
In a crude way, I'm implementing OAuth (or something like that).
The question here is - how should I be storing the primary user's credentials to the other site? The key point here is that mysite.com uses these credentials to provide access to the secondary users, so it MUST be able to read it. However, I want to store it in such a way, that the primary users are reassured that I (as the site owner) cannot read their credentials.
I suppose this is more of a theoretical approach question. Is there anything in the world of cryptography that can help me with this?
Text added:
Since most ppl are completely missing the question, here's attempt #2 at explaining it.
PrimaryUser1 has a username/password to www.something.com/PrimaryUser1Site
He wishes to give sub-access to two people- SecondaryUser1 and SecondaryUser2 to the folders- www.something.com/PrimaryUser1Site/SecondaryUser1 and www.something.com/PrimaryUser1Site/SecondaryUser2
Mysite.com takes care of this sub-user management, so PrimaryUser1 goes there and provides his credentials to Mysite.com. MySite.com internally uses the credentials provided by PrimaryUser1 to give subusers limited access. Now, SecondaryUser1 and SecondaryUser2 can access their respective folders on www.something.com/PrimaryUser1Site through the MySite.com
NOW, the question arises, how should I store the credentials that PrimaryUser1 has provided?
First rule: Never, ever store passwords!
Second rule: Calculate a hash over password, with additional salt, and store this in your database.
Third rule: A username (uppercased) could be used as salt, but preferably add a little more as salt! (Some additional text, preferably something long.)
Fourth rule: It doesn't matter how secure a hashing algorithm is, they will all be hacked sooner or later. All it takes is time!
Fifth rule: The security of your site depends on the value of what's behind it. The more value the content has, the more likely that you'll be attacked!
Sixth rule: You will discover, sooner or later, that your site is hacked but not through a hacked password, but through a loophole somewhere else in your code. The biggest risk is expecting your site is secure now you've implemented some strong security.
Seventh rule: All security can be broken, all sites can get hacked, all your secrets can be discovered, if only people are willing to invest enough time to do so.
Security is an illusion but as long as no one breaks it, you can continue to dream on! Always be prepared for rough awakenings that will require you to rebuild your illusion again. (In other words, make regular backups! (Preferably daily.) Don't overwrite the backups of the last week and make sure you keep at least one backup of every week, just in case you discover your site was hacked months ago and all your backups ever since are infected!
Now, if you really need to store passwords, use a hash over username plus password. Then hash again with hash plus salt! Better yet, create a list of salts (just list of words) and whenever a new user account is created, pick a random salt word to use to hash his username plus password. Store the index of the salt with the user account so you know which one to use whenever he logs on again.
And:
Eight rule: Always use HTTPS! It's not as secure as most people thing but it does give a feeling of security to your users!Since you've added text, I'll add more answer.
Since you want user1 to grant temporary access to user 2, you'll need a secondary user table. (Or expand the user table with a parent user ID. Also add a timestamp to keep track of the account age. User 1 can create the credentials and this is done in the normal way. Just store a hash with combined username and salt. In this case, use the username of user 1 as additional salt! Just make sure you'll disable the user 2 account when user 1 logs off or when a certain amount of time has gone by. And allow user 1 to enable all accounts again that he created, so they can re-use an account instead of having to create new ones all the time.
Security isn't a matter that depend on primary or secondary users. In general, treat them the same way! Secondary users have an added bonus that you can use the primary account as additional salt. The rest of it has nothing to do with authentication any more. It's authorization that you're dealing with. And while authentication and authorization have a strong relationship, be aware that you should treat them as two different, stand-alone techniques.
When user 1 logs on, he's granted access to the primary site. When he grants access to user 2, user 2 gets a reduced set of roles. But this has nothing to do with storing user names or passwords. You just have an user-ID which happens to be member of certain roles, or groups. Or not, but those would be inaccessible.
They're both just users, one with more rights than the other.
It depends on the kind of authentication your primary site and the secondary site agree on. Is it forms authentication, HTTP Basic or HTTP Digest? If is forms or basic then you have no choice, you must store the password, so your only choice is to encrypt it. You cannot store a password hash as you must present the clear text during authentication for both forms and HTTP Basic. The problems that arise from storing the encrypted password are due to either incorrect use of cryptography (ie. you don't use an IV or salt or you don't use correctly a stream cipher), but more importantly you'll have key management problems (where to store the key used to encrypt the passwords and how to access it from a non-interactive service/demon).
If the 3rd party site accepts HTTP Digest then you're in better luck, you can store the HA1 hash part of the Digest hash (ie. MD5 of username:realm:password) because you can construct the Digest response starting straight from HA1.
I did not address how the user provision the secondary credentials (ie. how you get the secondary site username and password n the first place), I assume you have secured a protected channel (ie. HTTPS from client to your primary site).
BTW this assumes that the authentication occurs between your primary and secondary site and the secondary site content is tunneled through an HTTP request made to the primary site. If that's not the case and the secondary site is actually accessed straight from the browser, then the secondary site must support some sort of pre-authenticated token based authorization of third parties like OAuth. Relying on credential authentication and storing the credentials on the primary site when the credentials are actually needed by the browser has so many problems is not even worth talking about.
Have you thought about accepting OpenID like Stack Overflow does? That way you are not responsible for storing passwords at all.
There is only one way to do this, and it is probably too burdomesome for the users.
You could encrypt the users password with a public/private key, the user keeps their key so the password can be unencrypted only when the key is submitted back to your server. The only way to make this simple would to be to have some web browser plugins that auto submit the information.
And either way, you could always packet sniff the communication to/from the server so its still mostly pointless.
there has got be a better way to explain this :(
but if you just want to know how to store the passwords safely do this:
username:john, password:pass
key = '!!#ijs09789**&*';
md5(username.password.key);
when they login just check to see if md5(username.password.key) = is equal to the one in the db - you can also use sha1 and or any other encryption method.
http://us.php.net/md5 & http://us.php.net/sha1
Never store passwords in a database but store a salted and hashed version of every password.
Check this article if this is chinese for you.
If you want to store the password yourself the best apporach is to use a one-way hashing algorithm such as MD5 or SHA-1. The advantage of this approach is that you cannot derive the password from the hashed value.
Precisely which algorithm you choose depends the precise products you are using. Some front-end tools offer these functions, as do some database products. Otherwise you'll need a third-party library.
Edit
Secondary users ought to have their own passowrds. Why wouldn't they?
You're making it too complex. You need to stop trying to mix authentication and authorization.
What you want to do is establish credentials for everyone, not worrying at this point if they are "primary" or "secondary" users. Then on the main site, where you manage the users and the primary/secondary relationships, you can do the logic of which users are primary or secondary and store all that stuff in a table. You grant or deny whatever rights and sub-rights you wish to each secondary user whenever the primary users update their relationships with them. When they're done, you finally need to replicate the appropriate user credentials from the main site out to the secondary site(s).
Then when a secondary user wants to head to any site in your farm, they authenticate themselves only as themselves - they never impersonate the primary user! And they have only the rights you granted them when the primary users gave them "secondary" status.
--
OK, since you shot that solution down in the comment, consider this:
First, I doubt anything will be truly secure. You can always recover the secret if you monitor the users' activity.
Now, this is completely off the cuff, and I haven't cryptanalyzed it, but check into what is called a secret sharing scheme. Store the "effective" or "real" main-site primary user password as the shared secret. Use the salted hash of the password given by the primary user as one secret. Use the salted hash of the password given by the first secondary user as another secret, and so on for each additional secondary user. Don't store the salted hashes! Just store the salt and the protected shared secret.
When a user enters their password, you retrieve the protected shared secret, use the salt and hash of their password to produce the salted hash, decrypt the protected shared secret, and now you've got the original primary user password.