Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: OT: Storing encryption keys securely

by BrowserUk (Patriarch)
on Jan 24, 2017 at 14:26 UTC ( [id://1180215]=note: print w/replies, xml ) Need Help??


in reply to OT: Storing encryption keys securely

  1. You should never store passwords themselves, even if encrypted, if the encryption method is reversible.
  2. You should only store the result of combining the password with a per user (derived) salt and passing it through a slow, one-way encoding algorithm.
  3. To authenticate, you obtain the password combine with the derived salt and encode again. If the result matches the stored value, you authorise.
  4. To handle the forgotten password scenario, you generate a random password, encode and replace the encoded token in your database.

    Get the randomly chosen password to the user somehow* and then force them to change it immediately the first time they log in.

    Preferably, they should have to log in and choose their new password within a short time period; and where possible, from a previously known location/machine.

In this way, if your datastore for the encoded authentication tokens is ever stolen, the thieves would have to brute force every single token, because although the encryption method is the same for every token, and they may have also determined the derivation of the salts, the salt is different for each user. Thus they cannot just encode a dictionary of pass phrases with a single salt and search the database to see if any of the tokens match the result.

Ie. They would need to encode every word or phrase in their dictionary with the derived salt for each and every account. Choose a nice slow encryption mechanism and it becomes too time consuming to bother.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: OT: Storing encryption keys securely

Replies are listed 'Best First'.
Re^2: OT: Storing encryption keys securely
by Beatnik (Parson) on Jan 24, 2017 at 14:38 UTC
    Thanks! I figured out most of those steps before the post but somehow overlooked the fact that the unencrypted password will (once confirmed through hashing, with unique salt value) still be available for passing to third-party application in whatever format required. I feel silly not realizing this sooner!


    Greetz
    Beatnik
    ... I'm belgian but I don't play one on TV.
Re^2: OT: Storing encryption keys securely
by Beatnik (Parson) on Jan 25, 2017 at 15:40 UTC
    During my daily commute, I reprocessed my initial requirements and I realized I didn't consider a primary feature. My application will work as a temporary credential store. Exchange with the third-party application is expensive (time) and may not be functional at all times. My intention is to store encrypted credentials for as long as needed (considering low cost sync time and availability) but that could be more than just a few. I have no control on how the third party will take the credentials so I will have to be able to decrypt them. Again, security is something I will take on but the same question remains. Considering I have 20 non-synchronized (encrypted) credentials, Using a on-startup-keyphrase may not be an ideal approach as a keyphrase recovery will invalidate the non-synchronized credentials. Using an external key management solution (whichever approach) can be considered. My target audience might expect some flexibility in how keyphrases are managed so I'll have to look at different approaches.

    Thanks for the feedback!!


    Greetz
    Beatnik
    ... I'm belgian but I don't play one on TV.
      So, basically, it sounds like someone has "solved" their security problem by pushing it off on you. Good luck.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1180215]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2024-04-23 10:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found