Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

From this earlier question, I have a general need to obfuscate a set of third-party credentials stored in a user account, which are then used in an internal Winforms software client. The scheme from the accepted answer is below:

Password Creation and Encryption:

  • User, having already authenticated with the internal system, chooses a new password P for that system, and/or changes sensitive data D.
  • Client software hashes P with SHA-512 producing C.
  • Client splits C in half resulting in C1 and C2.
  • Client uses C1 and a randomly-generated IV as the key to encrypt D with AES-256, producing S (which includes the IV).
  • Client transmits U, C2 and S to server.
  • Server BCrypts C2 to produce H (which includes a random salt).
  • Server stores U, H and S in the server.

Normal Login:

  • User enters login credentials (Username U and password P).
  • P is hashed with SHA-512 to produce C/*C1*/C2.
  • U and C2 are transmitted to the server.
  • Server hashes C2 with BCrypt to produce H.
  • Server retrieves user record with username U and verifies H against stored value.
  • Server transmits encrypted user data S.
  • Client uses C1 to decrypt S, producing D.

This functions beautifully, except for one issue: because it's essentially a PBKDF, if you lose the password, you lose the data. At first that was acceptable, as the data could be reconstructed; however, end user complaints about having to reconstruct their user account after an admin password reset (which essentially nulls out the encrypted data) have made it less so.

I therefore need to implement something on top of the existing scheme that allows administrative data recovery and/or password reset. I have come up with the following; please comment:

Password Retrieval/Admin Reset:

  • When changing a user password, client software additionally retrieves a common 2048-bit RSA public key K1 from the server.
  • Client uses K1 (and a proper padding scheme) to encrypt C1, producing E.
  • Client transmits E along with other user data, which is stored in the DB by the server
  • When password recovery is desired, an admin authenticates with the server and requests S and E for the user, along with K1.
  • Admin also obtains the private key K2 from offline, physically-secured storage.
  • Admin uses K2 to decrypt E, producing C1.
  • Admin uses C1 to decrypt S producing D.
  • Admin chooses a new password for the user, and obtains a new C/*C1*/C2, then produces S and E, all the same way the client would normally.
  • Admin transmits U, C2, S and E to the server, which BCrypts C2 into a new H and persists U, H, S and E.
  • Admin transfers the new password to the user offline or otherwise secure from observation, and returns their source for K2 to its secure physical storage.

Advantages:

  • Obviously, it solves the problem; lost or forgotten passwords can be reset by the admin.
  • Data is still secure; no information is transmitted across a wire or stored in the DB or program code that could be used in that form to obtain sensitive data; not knowing the password, an attacker must either crack AES-256 encryption or crack RSA-2048 with OAEP in order to obtain the third-party credentials.
  • While passwords are resettable, they are never recoverable; the admin never sees or knows the plaintext password the user had originally chosen. That password is the user's, and theirs alone (the password created by the admin can be treated as "temporary" and so required to be changed after one use).
  • If the admin, for any reason, doesn't have access to the specific private key of the pair that was used to encrypt the user's password-based symmetric key C1, they can still fall back to the "blow it away and recreate it" method of restoring the user account.

Disadvantages:

  • An additional piece of information must remain secure; the private key K2. This is not a human-consumable piece of information, and so must be stored in digital form; therefore that key storage must be physically isolated and secured, similar to (but probably not as well as) the private key for CA certificate generation.

The question is, is there anything I'm missing that would make this added piece of the scheme unsuitable or unworkable?

share|improve this question
    
What's wrong with generating a random encryption key, then encrypting that with both an asymmetric encryption algorithm such as RSA (where the private key is kept secret), and a key derived from the user's password (using e.g. bcrypt)? Store the two versions of the encrypted key separately. Then use the random key (plaintext to the key encryption) to encrypt the data. Maybe I'm missing something, but it seems like it has the same advantages and disadvantages, plus would appear to be a much simpler scheme. –  Michael Kjörling Dec 18 '12 at 19:28
    
What's wrong is that the existing scheme, using a password-derived symmetric key for the user data, is already in place and working. I can add the proposed password recovery method to it relatively trivially; the next software update can see that the field for the encrypted symmetric key is blank, and run through the asymmetric encryption at the user's next successful login. Changing the already-existing scheme would require allowing both systems to work in parallel, to support logging in the old way, then converting to and using the new way, until all users have logged in. –  KeithS Dec 18 '12 at 19:55
1  
In addition, the current scheme is a two-stage hash; one half of one hash is used as the key and never sent over the wire; the other is re-hashed server-side for password verification. If whatever value was used for password verification also encrypted the credentials, even with a re-hash on the server side for verification, if an attacker sniffed that hash as it was sent they now have the sensitive data. –  KeithS Dec 18 '12 at 20:11

1 Answer 1

up vote 6 down vote accepted

The best cryptographers use cryptography only when necessary. That being said, this proposed design is needlessly complex. Your design incorporates two different hash functions, symmetric and asymmetric encryption. Further more you make no mention of what attacks you are trying prevent, which leads to a superstitious design that is difficult to independently verify.

Use SSL it is a beatitude and proven design. It is light weight, its free and best of all IT IS SECURE.

In terms of the "logging in" functionality. Kerberos has a proven design for identity management and mutual authentication. Kerberos is distributed which is ideal for the cloud. Its beautiful because its so simple. A kerberos ticket is similar to the C1 variable in your system, in that is carries the user's identity. However it is also has a "ticket validity period" or timeout, which your system lacks. Kerberos tickets are created using only a block cipher, a hash function or asymmetric cryptography is not required. This design element reduces the computational resources needed for authentication.

Password reset? Just use a Cryptographic Nonce stored in a database! If the know the secret then then they can reset the password. The Nonce can be protected with encryption, and this could prevent vulnerabilities like SQL Injection from reading this Nonce and resetting the password.

In terms of addressing the root of the question. You are intentionally weakening the system to attack by introducing a backdoor. It would be ethical to inform your customers that this system has a backdoor. That being said you can implement such a backdoor using a Key-Encryption Key (KEK). You should also probably read the AES Key-wrapping Specification. A KEK can be used to easily change the encryption key used for a dataset after a compromise. The same property can be used to change the "password" used to protect data.

Complexity is the worst enemy of security

--Bruce Schneier.

share|improve this answer
    
I don't agree. Basically what I am trying to protect is an additional set of credentials to a third-party cloud system representing a key repository for sensitive data about us, our clients, and the systems and services we offer them. Those credentials are needed to connect to that cloud system as the same identity that is logging into our internal software. In addition, because people tend to use the same password for everything, I can hash the internal password all I want, but the password for the internal system is sitting right there in plain text. –  KeithS Dec 19 '12 at 0:43
    
Therefore, I must encrypt the third-party password by some means that an attacker must not be able to discover, either by decompiling our internal software, obtaining a dump of our database, or sniffing traffic. Basically, I want to ensure that if an attacker obtained the third-party credentials, it was not the fault of my application. The basic scheme incorporating the BCrypted hash was the answer to that problem. Nothing an attacker can sniff, dump or decompile gives then enough information to recover the credentials; there would have to be a keylogger installed (not my problem). –  KeithS Dec 19 '12 at 0:49
    
However, this was deemed a bit too secure. Users complained that if they forgot their password, they pretty much had to set up their account again from scratch. Hence, the recovery method, which I need to remain as secure as I can get it. Requiring admins to enter a secured, video-monitored room using a keycard that logs their entry, in order to obtain the private key, hopefully in a non-distributable form, is about as secure as I'll get, given that the building is built to standard commercial code and a few swings of an axe will get you anywhere you want. –  KeithS Dec 19 '12 at 0:55
    
Last word on this; who's to say this is needlessly complex? SSL uses, as part of the standard handshake, at least two different RSA key sets (if not four, to provide two-way client-server authentication), an SHA hash and a negotiated symmetric key. How is my authentication scheme "needlessly complex" given all that rigamarole? –  KeithS Dec 19 '12 at 1:15
1  
@KeithS Just about everyone on security.se will go ape shit if you suggest replacing SSL with a home-brew system. I am one of these people. From experience I think that reinventing the wheel is one of the worst evils in the security industry. This discussion is not building a secure system, it is a learning experience for you and a waste of everyone Else's time. –  Rook Dec 19 '12 at 17:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.