8

I need to use an external service that can only be accessed by password.

I don't like the idea of storing the plaintext password on the server, but AFAIK there's not much I can do.

Considering this service will only be accessed by a client (that also can't know the whole password), my idea to try to make things a bit harder for a hacker, is to store "half" of the key on the server, and "half" of the key on the client.

I know this also can't be perfect, and that someone who gets full access to the server will be able to find out the password, but it's better than nothing. (Other suggestions are welcomed.)

Considering the password changes from time to time, and that I don't want to change the "server half" of this password, my best idea so far is this:

  1. Generate a random key K and store it on the server
  2. Encrypt password (P) with K, generating E, and give E to the client
  3. Now, everytime the client wants to access the service, it provides E and the server will decrypt E using K.
  4. When the password (P) changes (to P'), I just need to encrypt it with K again and provide the new E' to the client.

Does this seems reasonable? Any other ideas?

4
  • How about a ssl client authenticated session where you send your public key to the server and authenticate yourself with your private key ??
    – Arun
    May 20, 2014 at 9:53
  • 3
    This sounds very much like public / private key cryptogrophy, read up on it and see if there might be a other way to do this.
    – Alex
    Mar 16, 2015 at 12:59
  • You'd want to read on Shamir's Secret Sharing Scheme.
    – Lie Ryan
    Oct 12, 2015 at 13:10
  • 2
    Shamir's Secret Sharing Scheme is useful for when want to split a password into more than two parts, and only require a specific number of parts and not all of them (like 2 out of 3) to rebuild the full password. If you want all parts to be required, then ssss is overkill. If the full password is a good random value, then simpler strategies include XORing all of the parts, or even just concatenation (as long as each part is a good length).
    – Macil
    Feb 10, 2016 at 0:31

2 Answers 2

1

I don't understand completely the scenario, could you provide a simple ASCII diagram?

Anyway, I don't really like the idea of giving E to the user since it will be a very hard password to remember, maybe you can do it in the other way, give K to the user (so you can choose it) and store E in the server.

I will edit my response after the scenario clarification :)

4
  • I'm not good with ASC drawing, but I think you got it correctly. Basically, I need the server to be able to arrive at the string "PASSWORD" without having it hardcoded. So my solution is encrypting PASSWORD with a random secret (K), producing E. Then the client knows E and the server knows K. When the server receives E, it decrypts it with K to arrive at "PASSWORD". But one day "PASSWORD" might be changed to "PASSWORD123", and I don't like changing the server. That's why I give E to the client (which is actually an app that runs on another server, not a human).
    – Lem0n
    Jan 18, 2014 at 23:03
  • And, why don't you give the password directly from the user to the server? Is there any problem for the client to know it?
    – kiBytes
    Jan 18, 2014 at 23:05
  • Yes, the client can't know the final password too.
    – Lem0n
    Jan 18, 2014 at 23:28
  • 2
    And how about using just a long password divided in two parts? You can use a fixed part in the server (randomly generated) and you can append or prepend it with the other chunk of the password (that now can be human readable if needed). If you want to change the password you can use the same part for the server and change the user part. After all, once the server is hacked is a matter of time for the hacker to obtain "E". So I don't really see the benefit in making such operations.
    – kiBytes
    Jan 18, 2014 at 23:53
1

If you cannot work with a client certificate (which would be preferable) then yes this may be a good solution but remember if the application is hacked it's game over (as always).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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