I have a question about storing encrypted passwords in your database to help secure them. I have a class that encrypts the password passed in and returns a string. This string has 3 parts too it, all separated by a colon. The first part is the iteration, the 2nd part of it is the salt, and the third part of it is the encrypted password. Ex: "1000:{salt}:{encrypted password}".

My question is how am I suppose to store this? As of right now, I am storing the entire string in my database under the password column. Then when I go to check the passwords for a login, I retrieve that record, and I have a method in my class that parses it and verifies that the two passwords match. Is this a big 'no no?' I've read where some people store the salt in it's own column then pull that down when verifying a login. However, this class that I am using for the encryption will return a string like I showed above. Then it came with a method that I can just pass that entire string into it and it will parse it up and verify the passwords as a login.

I guess what I'm asking is, do I need to re-construct my class to separate the string ("{iteration}:{salt}:{encrypted password}"), or is storing that entire string in the database OK?

  • You are supposed to store them using a library. It is NOT OKAY for you to be writing your own security protocol. – ArTs Jan 11 '16 at 5:19
  • 1
    Microsoft membership stores all of the parts in one column. Do yourself a favor Brandon and learn to use the membership or simple membership classes. For simple membership it's really not all that difficult and the knowledge will last you a lifetime. If you are developing an application you are by definition not qualified to do security and security is not to be taken lightly. – Alternatex Jan 11 '16 at 6:46
  • 2
    Note that if you're using PBKDF2-HMAC-SHA-1 then 1000 iterations is very low. I recommend 20k+ iterations. I'd also include a version specifier in your string, in case you switch to an entirely different algorithm (such as bcrypt, scrypt or Argon2 which offer better security than PBKDF2). – CodesInChaos Jan 11 '16 at 10:55
  • 1
    @CodesInChaos On the contrary, I've found Simple Membership to be very robust a breeze to learn and use. – Alternatex Jan 11 '16 at 12:07
  • 1
    @Alternatex Thanks for your input. It's appreciated very much! – James Jan 12 '16 at 0:55

What you do is how most are doing it, and it is perfectly fine.

The thing people say about not doing your own security is that you should not invent your own way of hashing the password. Always use a state of the art password hashing algorithm.

So store the hashed password including the individual salt and the number of iterations (which allows you to increase the number of iterations later if you need to) in the database.

| improve this answer | |
  • Security is a lot more than just hashing passwords. This is why we urge developers not to act like security experts. – Alternatex Jan 11 '16 at 10:02
  • @alternatex Could you please provide links to authoritative sources that how you store the password hash including salt in a database is a security issue in itself. As it is now your claim is unsupported. – Bent Jan 11 '16 at 10:24
  • This might be of help – Alternatex Jan 11 '16 at 10:25
  • Where does it say anything about how to store the resulting password hash in a database? You are not worth my time anymore. – Bent Jan 11 '16 at 10:39
  • How to store a password in a database is not an important question. The important thing is to realize there's more to security than how you handle the password. This is why we shouldn't encourage OP to handle things like this himself and also the reason there's so little interest in the question here. – Alternatex Jan 11 '16 at 10:47

While developing an application I was using an Encryption Library that had the same format {iterations}:{salt}:{PasswordHash}. It had 2 main methods public string GetPasswordHash (string PlainTextPassword) and public bool VerifyPassword(string formatedPaswordHash, string PlainTextPassword). Since GetPasswordHash returned and VerifyPassword expected a string in the {iterations}:{salt}:{PasswordHash} format that is how I stored it in the database. It was then a simple retrieve hash from DB, Pass to Verify method and not have any additional code to deal with.

I could have broken it up into 3 columns (Iterations, Salt, PasswordHash) but then I would just have to combine them again to verify adding a step that could introduce a bug. Since I would never manually update any of the parts I saw no benefit to storing them separate, especially when an attacker could break them apart or put them back together as easily as I could if they got access through a different bug.

Overall either way can be defended but I always tend to go with keeping things simple. If the library spits out a string from one method and expects a string in the same format to be passed into another method, why bother changing the format for storage if we are not going to manually update any of the individual parts.

The only big no no of encryption is to not roll your own GetPasswordHash and VerifyPassword. As long as those are strong, how you store things in the database becomes a secondary concern.

| improve this answer | |
  • Yeah, that's pretty much exactly how the library I'm using works. I just didn't know if it was bad to store the entire string in the DB. Thanks for your input - it helped! – James Jan 12 '16 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.