How to Best Store User Information and User Login and Password

How to best store user information and user login and password

Don't store passwords. If it's ever sitting on a disk, it can be stolen. Instead, store password hashes. Use the right hashing algorithm, like bcrypt (which includes a salt).

EDIT: The OP has responded that he understands the above issue.

There's no need to store the password in a physically different table from the login. If one database table is compromised, it's not a large leap to access another table in that same database.

If you're sufficiently concerned about security and security-in-depth, you might consider storing the user credentials in a completely separate data store from your domain data. One approach, commonly done, is to store credentials in an LDAP directory server. This might also help with any single-sign-on work you do later.

Best way to store password in database

You are correct that storing the password in a plain-text field is a horrible idea. However, as far as location goes, for most of the cases you're going to encounter (and I honestly can't think of any counter-examples) storing the representation of a password in the database is the proper thing to do. By representation I mean that you want to hash the password using a salt (which should be different for every user) and a secure 1-way algorithm and store that, throwing away the original password. Then, when you want to verify a password, you hash the value (using the same hashing algorithm and salt) and compare it to the hashed value in the database.

So, while it is a good thing you are thinking about this and it is a good question, this is actually a duplicate of these questions (at least):

• How to best store user information and user login and password
• Best practices for storing database passwords
• Salting Your Password: Best Practices?
• Is it ever ok to store password in plain text in a php variable or php constant?

To clarify a bit further on the salting bit, the danger with simply hashing a password and storing that is that if a trespasser gets a hold of your database, they can still use what are known as rainbow tables to be able to "decrypt" the password (at least those that show up in the rainbow table). To get around this, developers add a salt to passwords which, when properly done, makes rainbow attacks simply infeasible to do. Do note that a common misconception is to simply add the same unique and long string to all passwords; while this is not horrible, it is best to add unique salts to every password. Read this for more.

How should I ethically approach user password storage for later plaintext retrieval?

How about taking another approach or angle at this problem? Ask why the password is required to be in plaintext: if it's so that the user can retrieve the password, then strictly speaking you don't really need to retrieve the password they set (they don't remember what it is anyway), you need to be able to give them a password they can use.

Think about it: if the user needs to retrieve the password, it's because they've forgotten it. In which case a new password is just as good as the old one. But, one of the drawbacks of common password reset mechanisms used today is that the generated passwords produced in a reset operation are generally a bunch of random characters, so they're difficult for the user to simply type in correctly unless they copy-n-paste. That can be a problem for less savvy computer users.

One way around that problem is to provide auto-generated passwords that are more or less natural language text. While natural language strings might not have the entropy that a string of random characters of the same length has, there's nothing that says your auto-generated password needs to have only 8 (or 10 or 12) characters. Get a high-entropy auto-generated passphrase by stringing together several random words (leave a space between them, so they're still recognizable and typeable by anyone who can read). Six random words of varying length are probably easier to type correctly and with confidence than 10 random characters, and they can have a higher entropy as well. For example, the entropy of a 10 character password drawn randomly from uppercase, lowercase, digits and 10 punctuation symbols (for a total of 72 valid symbols) would have an entropy of 61.7 bits. Using a dictionary of 7776 words (as Diceware uses) which could be randomly selected for a six word passphrase, the passphrase would have an entropy of 77.4 bits. See the Diceware FAQ for more info.

• a passphrase with about 77 bits of entropy: "admit prose flare table acute flair"

• a password with about 74 bits of entropy: "K:&$R^tt~qkD"

I know I'd prefer typing the phrase, and with copy-n-paste, the phrase is no less easy to use that the password either, so no loss there. Of course if your website (or whatever the protected asset is) doesn't need 77 bits of entropy for an auto-generated passphrase, generate fewer words (which I'm sure your users would appreciate).

I understand the arguments that there are password protected assets that really don't have a high level of value, so the breach of a password might not be the end of the world. For example, I probably wouldn't care if 80% of the passwords I use on various websites was breached: all that could happen is a someone spamming or posting under my name for a while. That wouldn't be great, but it's not like they'd be breaking into my bank account. However, given the fact that many people use the same password for their web forum sites as they do for their bank accounts (and probably national security databases), I think it would be best to handle even those 'low-value' passwords as non-recoverable.

Where to store user login information?

It depends about your needs.

Session:

• saved on server so consume server resources
• most secure (no one can modify session data)
• lost when user close browser

Cookie:

• saved on client browser (doesn't consume server resources)
• is less secure because it's accessible on the client pc and on the network (so is a good idea to encrypt cookies, specially login informations cookies)
• you can persist it through different session

Generally speaking when you have a problem like "rather than having to requery the database on every page" ask yourself if you can use ASP.Net Caching

What's a smart way of storing user credentials for an external site (that does not use OAuth)?

IMO opinion you should not take responsibility to store the credentials somewhere on your file system. Just think that even the 3-rd party server does not know the user credentials (would have the hash of the password and not the actual password stored).

I would recommend to store them as part of an http-session which lasts as long as the session is active.

How do I securely store/get user information on the client side in web development?

How can I save the client's information in a way that is unable to be tampered with?

Encrypt it on the server. Never give the decryption key to the client. This is how JWT works.

Obviously, this doesn't work if you need the contents to be available on the client.

Is there a way to hide the information in my POST responses so they cannot be viewed by dev tools?

No.

---

It doesn't seem right that anyone can see the list of users with their database ID, but I need that information for when users interact with each other.

If you need to tell users that other users exist, then they have to know about them.

The database ID shouldn't be critical information.

If you want to stop a user posing as another user, then use authentication. Require a username + password or something that represents them (like a JWT).

What is the best way to store a user name and password for a Windows Service?

The DP API is the standard way of locally storing sensitive data on Windows. You didn't mention the programming language you're using, but in .NET this is exposed from the System.Security.ProtectedData class.

---

Related Topics