loading...

Things you wanted to know about storing passwords but were afraid to ask

Rui Figueiredo on December 04, 2017

Security breaches are very common. To make matters worse, when it comes to users' passwords it is frequent that no reasonable precautions were ta... [Read Full]
markdown guide
 

And any recommendations/things to read about reversible passwords storing? When the password is absolutely needed to be accessed in plaintext when using it. So the flow: user enters a password, encrypt it (don't really care about timing here), store in DB, when needed - retrieve from DB, decrypt and send to a 3rd party service in plaintext. I know that this is bad, but there are no workarounds.

 

If the passwords are stored correctly, and the password you are trying to retrieve is a "good" password, what you are trying to do should be impossible to achieve in any reasonable amount of time.

 

I try to store (more or less) securely the password but in a reversible way. Are you referring to this case?

If it's reversible by you it means it is reversible by someone else, therefore it's not secure.

I know that, of course.

ANY password stored in any way is not 100% secure, but for reversible - which is the only way for me for my particular case - what are the best options?

I don't talk / ask about whether it's secure to store like that or not.
I want to avoid storing the password in plaintext.

I suppose when you say reversible you mean they are encrypted. Do you know which algorithm was used?

Em, we seems to be talking about different things.
I don't need to decrypt passwords stored by someone else.

My users will enter their password in my app. I need to store that info in DB and then reuse later but decrypted. I can select any algo to crypt. I want to get insights of how to better do that, so at least it won't be too obvious to decrypt by someone else having access to DB.
This app is open sourced, so definitely, some salt should be used (and they are unique for all users on their sites).

You should look up how the password reset functionality works, that way there's no need to ever recover passwords in plain text.

Have you read the article? I was hoping this would be something that was clear after reading it, if not then I clearly failed.

No, the article is good, you just can't understand my use case. Seems I'm too vague, sorry. But I can't go into more details, will try to find answers elsewhere.

Reset passwords is just marking the password as deprecated and ask a user to change it without decryption (and resave the hashed value in DB). And I must decrypt and be able to [password => hashed in DB => password].

That's not how hashes work.
Anyway if you have time I recommend reading how password storage is done in ASP.NET Identity. Looking at a concrete example might help.

Slava's asking how to securely store the user's password so that his app can then talk to another app as if it were that user. On that user's behalf.

Because the other app needs the user's password, he needs some way to store and retrieve the user's password.

It's tangential to the discussion here.

Slava, you need to look to see if this "other app" has some other way to allow users to delegate access. This is where OpenID and OAuth, etc., come in.

I use OAuth2 when possible, but it's not always the case. I have to support this old-school insecure way, so trying to be less evil by searching the way to improve the password storage.

 

I've seen/read somewhere else about adding "salt" to passwords for storage, but never as clearly explained and with use cases as in your article. Thank you.

code of conduct - report abuse