0

I'm trying to figure out the best way to encrypt passwords for a forums site I'm working on.

I've decided I'm going to use an encryption such as blowfish. From my understanding, you have a key, and the text you want to encrypt. The encryption then uses the key to encrypt the text. When a user creates an account, I plan on generating a UUID for them. That will be the primary key when they're put in the database with their encrypted password.

Now, I don't plan on letting the users be able to find out their UUID, because it will only be stored in PHP sessions. But, let's say, somehow someone finds out the user's UUID.

Would it then be possible to decrypt their password? Would they even be able to find the UUID from a php session? If there is an issue with this concept, should I generate a key to use and store it in the database with their UUID and password?

Sorry if the question's confusing, I'm not very good at putting my thoughts into words. Thank you in advance.

bcxavier92
  • 1

2 Answers2

5

Well, let's use proper terminology then.

You don't want to encrypt passwords. You want to hash password. This is something completely different. Read this. There is a good password hashing function called "bcrypt" which is internally derived from an encryption algorithm called "Blowfish"; from which came a lot of confusion with some software platforms claim to do "password encryption with Blowfish", when they really mean "password hashing with bcrypt".

Now there is also an overload on the meaning of key. In cryptography, a "key" is a piece of secret data that is used as part of a cryptographic algorithm. Password hashing does not use any key (precisely because it is not encryption, despite the widespread terminology abuse). In databases, a "key" is some value that is used to reference a row in some table. This is not at all the same kind of key.

UUID are values which are meant to be unique (worldwide), but that does not mean that they cannot be guessed. Only that when you generate UUID "properly", then you will not get the same UUID value as any other person in the World who also generates UUID properly. Thus, UUID can be good for database keys (although worldwide uniqueness is some overkill), but not for encryption keys (but password hashing needs no key). UUID can be good for salts, a component of password hashing.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • For completeness, aren't HMACs sometimes used for hashing passwords? (your answer [here](http://security.stackexchange.com/a/29955/61443) indicates that PBKDF2 uses an HMAC internally). Where do they get their crypto keys? – Mike Ounsworth Jul 28 '15 at 20:12
  • 1
    HMAC is an algorithm that uses a key to produce a MAC (Message Authentication Code). Some people use a MAC instead of hashing, and then they have a key (which is quite sensitive). Also (and this is a completely different notion), HMAC happens to be a good implementation of a mathematical concept known as PRF (Pseudorandom Function Family -- yes, I know the acronym does not match), and as such is an internal building block for some algorithms, e.g. PBKDF2. – Thomas Pornin Jul 28 '15 at 20:21
  • Well, a PHS can use secret keys, but it's rather uncommon. Argon2 is an example for such a scheme. – SEJPM Jul 29 '15 at 17:01
1

You don't want to encrypt passwords, because with encryption, the encryption key and the encrypted data can produce the unencrypted data. If someone gains access to your data store, they can recreate the original password. With a hash, you don't store enough info to recreate the original data. All you can do is verify that input data produces the same hash value.

Philip Tinney
  • 130
  • 5