SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    Best way to securely store retrievable password?

    So I've been tasked to add a feature to our company admin area where staff can store passwords they need for other sites.
    I know this is fraught with trouble, but maybe more secure than a series of post-it notes on desks!

    My first attempt was to use mcrypt to get an encoded string and initialisation vector. I'd store both of these in the database so that I can, with the required key, retrieve the password, eg
    Code:
    $cipher="rijndael-256";
    	$mode="ofb";
    	$keystring = "somethingsomething";
    	
    	$td = mcrypt_module_open($cipher, '', $mode, '');
       $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_RANDOM);
       $ks = mcrypt_enc_get_key_size($td);
       $key = substr(md5($keystring), 0, $ks);
       mcrypt_generic_init($td, $key, $iv);
       $encrypted = mcrypt_generic($td, $str);
       mcrypt_generic_deinit($td);
    However, all of the keys and everything is stored on the server. So, although someone hacking the database, wouldn't be able to retrieve the passwords, someone with access to the code and the database (eg another developer) would have all they need to decipher the password.

    My next idea is to use user input as the key. This does, however, mean that if (or when) the user forgets their password the passwords are lost.

    Any other ideas/input?

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Using something like Lastpass or Roboform is out of the question? o.o

    Well...I would actually have the Database on its own server. Have the web site on its own server, Have the admin area on its own server. I assuming there is a public component to this? Anyways The admin server would only be accessible from within the company network. That would remove one aspect of hacking.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    2 Thread(s)
    @hessodreamy

    I like logic_earth's take on this is good for a number of different security angles. Maybe consider public access to this only through a VPN tunnel (like OpenVPN) to access this from their phone or home connection. The nice thing is that as long as people carry their VPN certs then they can access it securely with very little setup.

    I would implement this as a one way hash for people to log in and gain access to their stored credentials. I would then use a two-way encryption to protect clear-text views of the data.

    Steve
    ictus==""

  4. #4
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,149
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Let me first start by reiterating what others have said, that your company would be better off using existing tools. Personally, I use KeePass.

    That being said, if your company still insists on proceeding, here's what I would do.

    First, storing the encryption key in the database or code makes the whole thing rather pointless. Anyone who can access the db could also access the key. You had the right idea to solve this: use user input as the key. In fact, this is how existing password management systems work. The user enters one master password that is used to protect all their other passwords.

    Next, if you want to protect users from their own forgetfulness and be able to retrieve their passwords even if they've forgotten their master password, then you'll have to use public-key crypto. The idea behind public-key crypto is that you have two different keys: one only encrypts, and the other only decrypts. This means you can keep the encryption key in your database, while the decryption key remains privately in your head. Every time a user updates their data, you'll store two copies. One copy is encrypted with Rijndael using the user's master password, and the other copy is encrypted with your public encryption key. So even if the user forgets their master password, you'll still have a copy that you can decrypt.

    And finally, to re-reiterate... don't try this unless you absolutely must.

  5. #5
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,190
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    In general, depending on the security level you need on this, it can both be very easy to implement (low security) or very hard (high security).

    If we are talking about a small company, and not that many passwords, your security threshold can be low. On the other hand if we are talking about storing passwords for thousands of customers, we are in a total different game park.

    Quote Originally Posted by logic_earth View Post
    Using something like Lastpass or Roboform is out of the question? o.o
    The different password storing solutions that is available is actually not as secure as they "claim" in their information and ToS/Privacy settings.

    We reviewed most of those on the marked a year ago to see if we could use them internally in the company, both to store our own information and our customers information. I.e. make it available both to our developers and our customers accounts. The problem with them all (when we checked them) is that due to the functionality they offer, its impossible to keep the level of security they claim to have. This might have changed now, but unless they have removed functionality or rewrote their implementation of it, then the passwords you have can be accessed by said company.

    Please note this is just a security issue we located by theory regarding how encryption works and what they required for the additional accounts and the ability they offered, makes the claim that "only you have access to your passwords" mute. There might be more or less security issues as well if you do a white box audit.

    Quote Originally Posted by Jeff Mott View Post
    First, storing the encryption key in the database or code makes the whole thing rather pointless. Anyone who can access the db could also access the key. You had the right idea to solve this: use user input as the key. In fact, this is how existing password management systems work. The user enters one master password that is used to protect all their other passwords.
    A good example on how the OP can setup this.

    I would also recommend against using a public key crypto unless required, and if you do decide to use this you need to make certain that people understands that you use this. Mainly as this does mean that anyone that has access to your servers can get a hold of the information encrypted from the public encryption containers. (Note I am both thinking on rogue staff, and if the servers get hacked).

  6. #6
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,149
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TheRedDevil View Post
    ...if you do decide to use [public key crypto] ... this does mean that anyone that has access to your servers can get a hold of the information encrypted from the public encryption containers. (Note I am both thinking on rogue staff, and if the servers get hacked).
    Rogue staff -- sure. But hacked servers -- no. The decryption key doesn't need to be saved on any server.

  7. #7
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TheRedDevil View Post
    The different password storing solutions that is available is actually not as secure as they "claim" in their information and ToS/Privacy settings.

    We reviewed most of those on the marked a year ago to see if we could use them internally in the company, both to store our own information and our customers information. I.e. make it available both to our developers and our customers accounts. The problem with them all (when we checked them) is that due to the functionality they offer, its impossible to keep the level of security they claim to have. This might have changed now, but unless they have removed functionality or rewrote their implementation of it, then the passwords you have can be accessed by said company.

    Please note this is just a security issue we located by theory regarding how encryption works and what they required for the additional accounts and the ability they offered, makes the claim that "only you have access to your passwords" mute. There might be more or less security issues as well if you do a white box audit.
    In the case of LastPass, the Master Key used for encryption and decryption, never leaves your computer. It would be impossible for LastPass to retrieve the private information (passwords) from their database, as it is encrypted before it leaves your computer. All of the encryption and decryption takes place on your personal computer. Now unless you know of a way to break AES then by all means, lets hear it.

    http://lastpass.com/whylastpass_technology.php
    ...Complete security, while still providing online accessibility and syncing capabilities. We've accomplished this by using 256-bit AES implemented in C++ and JavaScript (for the website) and exclusively encrypting and decrypting on your local PC. No one at LastPass can ever access your sensitive data. We've taken every step we can think of to ensure your security and privacy.

    ....

    On Windows, LastPass helps find insecure passwords stored on your computer so you can store them securely in LastPass and remove the easy access by malicious software. LastPass uses SSL exclusively for data transfer even though the vast majority of data you're sending is already encrypted with 256-bit AES and unusable to both LastPass and any party listening in to the network traffic...Our policy of never receiving private data that you haven't already locked down with your LastPass master password (which we never receive and will never ask for)
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.



Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •