0

Hi I'm developing a PHP website that has an integration with a 3-party solution which I have to register the API credentials to generate a token for the requests.

I already know that the safest way to store passwords in DB is getting the hash or encrypting the password, but in this case I'll need the password in clear text to generate the token.

How can I securely store this password in database or config file?
And if I have to use encryption functions how to store the salt to recover the password?

The main thing is that I need to recover a password in clear text, but if my database is compromised the attacker won't be able to recover the password.

dudz
  • 1
  • Related: https://stackoverflow.com/questions/2283937/how-should-i-ethically-approach-user-password-storage-for-later-plaintext-retrie?rq=1 – Jacob Sep 20 '18 at 16:31
  • Encrypt the passwords. – The Impaler Sep 20 '18 at 17:38
  • FYI, salting is only useful to make hashing stronger. It's not relevant to encryption. You don't need to add a salt to the content before encrypting it. – Bill Karwin Sep 20 '18 at 17:54
  • @BillKarwin Salting is typically part of the encryption algorithms. That's why if two people use the same password they are saved as different encrypted values. – The Impaler Sep 20 '18 at 17:59
  • @TheImpaler, You're thinking of hashing. – Bill Karwin Sep 20 '18 at 18:00
  • Nope, I worked implementing PCI solutions to encrypt and decrypt credit card numbers: that is symmetric encryption. Salting was a bona fide requirement. – The Impaler Sep 20 '18 at 18:01
  • If you use encryption, then an attacker to your application server can access all the passwords. – kelalaka Sep 21 '18 at 08:00
  • @TheImpaler, Thanks! I learned something. – Bill Karwin Sep 22 '18 at 05:11
  • @BillKarwin Oh man, I'm so grateful to SO. When I joined I thought I already knew a lot. Now I'm much more humble. After learning quite a bit here -- I think I have so much to learn ahead of me :D – The Impaler Sep 22 '18 at 15:10

2 Answers2

1

Encrypt the password, do NOT hash it.

When you hash a password, you lose the password forever and you get a "projection" of the password itself that doesn't allow to go back and produce the original password. Hashing is usually the safest option to authenticate since there's no way anyone can reproduce the original password. But you cannot hash it, since you need the password back at some point.

Therefore, encrypt it. There are several encryption grades, from the most basic one to the strongest one. I don't know how secure you want the encryption. Here's a simple (non-comprehensive) list of the typical options:

1. Encoding

Encoding is NOT encryption. When we encode some data we replace the characters by other ones. Think of the 2000-year old ROT-13 that Julius Caesar used (did he?). An A becomes an H, B becomes T, etc. Anyway this is NOT encryption but just a simple transformation that will fool a child, or a person with no technical background only. Other most typical encodings include Base-64, and simple Hexadecimal.

2. Weak encryption

Weak encryption includes all symmetric encryption that use no salting, and internal or short keys (less than 256 bits). Typical case is the use of simple passwords.

3. Medium encryption

This includes symmetric encryption with larger passwords (or keys with a bit length of 256 or more), salting, but internal passwords/keys. This is quite useful and I have adopted this strategy several times. The salt is stored as the first 16 bytes of the encoded value. When unencrypting, the salt is separated from the encoded value (it's always 16 bytes).

4. Strong encryption

Is essentially the medium grade encryption but with the addition of a key management solution. The key is not fixed anymore, and is not stored in the application itself, but securely recovered externally when needed. The key is managed by external processes and is changed periodically. This entails some extra processing in your application.

The Bottom Line

For your case, I would use option #3 Medium encryption, unless you have strong reasons to try option #4. To me #4 is overkill.

The Impaler
  • 30,269
  • 7
  • 28
  • 55
  • What is the definition of *"larger passwords"*? There is no mention of a password to key derivation method such as PBKDF2 or Argon2i, just using a password is not secure. – zaph Sep 20 '18 at 18:07
  • The problem with *"Medium encryption"* is if a single password is used for encryption all passwords that password fill fall to the attacker that gains admin rights—that must be assumed thus not secure. – zaph Sep 20 '18 at 18:15
  • @zaph Yes, I used "larger password" in a vernacular way. I meant larger keys of 256 bit or more. And yes, you described the weakness of the "Medium encryption" quite well. – The Impaler Sep 20 '18 at 18:19
  • For *"Strong encryption"* it is best if the decryption is done on another server (or HSM) so the key is never on the Internet facing server. If another server is used there should be rate limiting and alarming and no Internet connection. – zaph Sep 20 '18 at 18:19
1

First really make sure you need to have the password, that there is no other way because if you have access to user's passwords both the users and you have a severe liability.

Saving passwords presents large security issues that require substantial safeguards.

Encryption of passwords along with random per password salting is required. The problem with encryption is that the key must be available and an attacker who gains admin privileges—and they will—will get the encryption key along with the encrypted passwords if both are on the server. At that point the attacker will have all of the passwords.

Instead the encryption keys, encrypted passwords or both should be on a separate device such as an HSM or dedicated rate-limited and rate alarmed computer in a secure site.

Obviously the encryption key must be good that generally means a 128-bit or greater (256-bit is a good choice) random symmetric key, passwords are not acceptable.

zaph
  • 108,117
  • 19
  • 176
  • 215
  • I totally agree with you on the encryption key safety. This is more of a high-grade encryption, though, and I'm not sure @dudz is ready to make such an effort. Anyway, it's a good explanation. Upvoting. – The Impaler Sep 20 '18 at 18:43
  • Yes, @dudz may not be ready, if that is the case the project should be abandoned. If an implementor can not provide user security they should not go ahead and put the users at risk. In a situation such as this I would (and have in the past) pay a senior cryptographer to vet the design and implementation. – zaph Sep 20 '18 at 18:49
  • @TheImpaler An aside: On the first mass market security project Worked on my boss did the security and it was a total security failure complete with beings Slashdot'ed. On the next project the VP of development came up with a scheme completely lacking any security, I told him that in an email and, had to fly 3,000 miles to apologize—but also got the company to hire a crypto expert to vet that and all future designs and implementations. One needs to standup for real security. – zaph Sep 20 '18 at 19:01
  • 1
    I'm with you on this one. I spent 6 years implementing PCI-compliant encryption layers in high end e-commerce sites on a "big red" company. We were audited every year, and I only strong encryption was accepted. – The Impaler Sep 20 '18 at 19:05