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.

I am working with several other people in writing software which requires authentication before it accesses resources. In order to authenticate, we devised the following strategy.

  • Client sends a SHA1 of a username to the server
  • Server responds with a user's unique ID, which is a public key in an RSA key-pair
  • Client creates a SHA256 hash of a user's login details, and encrypts it using the unique ID.
  • If the hash matches the hash of a user's login details, the server responds with a specific value, and records the timestamp of the moment the response was sent.
  • The client responds by encrypting the timestamp at the time it receives confirmation, and sends it to the server.
  • If the timestamp sent by the client is within x seconds of the server's recorded timestamp, the server considers the client authenticated.

Currently, the client-server communication will take place using SSL/TLS over TCP.

My question is as follows: Is this method secure enough and, if not, what can be done to improve it?

share|improve this question
1  
Please don't be a Dave. –  Adnan Mar 13 '13 at 18:49
4  
Is there a reason you're rolling your own rather than using a standard authentication protocol (Oauth, openid, SAML, etc.). And what does "Secure enough" mean? If you're securing nuclear weapons, then the answer is "NO". If you're securing your kid's kindergarten homework, then "yes". What is the consequence of the authentication going wrong? –  Mark C. Wallace Mar 13 '13 at 18:52
    
The decision not to use a standard auth protocol was, to my understanding, taken because we're not using HTTPS as our method of transferring information. The consequence of authentication going wrong is the loss of a number of potentially sensitive files on a potentially large number of machines. –  Liam McSherry Mar 13 '13 at 18:57
1  
SSL/TLS over TCP... even if you're not using HTTPS, you can still implement the same kinds of auth you normally see. –  Jeff Ferland Mar 13 '13 at 19:06
    
Is the user's unique ID (RSA public key) different every time the user logs in? Or more importantly, is the public key invalidated as soon as it is used? If not, the protocol inside the SSL/TLS tunnel is vulnerable to a replay attack. –  Ladadadada Mar 13 '13 at 19:09

1 Answer 1

up vote 9 down vote accepted

What are you trying to achieve ? In particular, why would you create a new RSA key pair ?

You use SSL; that's good. With SSL, the client has some strong guarantee that it talks to the right server, and that what the client will send will be readable only by that server. At that point, just send the user login and password through the tunnel. There is no need to fiddle with timestamps and additional public keys and hashing and whatsnot. SSL is enough.

On the server side, just store a password hash, as a second line of defence (you do not want someone who got a quick peek at the server's database to obtain a full list of valid passwords immediately). But this is on the server and irrelevant for the actual protocol. The protocol is: client connects to server with SSL, client sends login+password in the SSL tunnel, server verifies the password and is happy (or not).

If the SSL protection is not enough for you, then either the client or the server (or both) is under hostile control, and you have bigger worries, and there is nothing more you may do to fix that. Your games with extra keys and hashes and timestamp bring a lot of extra complexity and overhead, for no security benefit.

share|improve this answer
    
Thank you for the insight. The decision was made to use extra encryption and such because this software is intended to be used in the event that the client is under hostile control, and so any data communicated by this program would not be immediately readable by any attacker, should they be monitoring inbound and outbound traffic. –  Liam McSherry Mar 13 '13 at 19:23
4  
If the hostile entity has control of the machine, then he is monitoring keyboard, display, hard disk activity, and can see the very RAM of each process (and yes, attackers do that routinely). If you believe that your encryption antics would bring you some actual extra protection, then you are up for some disappointment. –  Tom Leek Mar 13 '13 at 19:29
    
The software is intended to provide a little bit of extra security in the event that a device is stolen or lost. Rather than attempt to thwart the most knowledgeable of attackers, it attempts to mitigate the consequences of your everyday thief, or maybe a reasonably tech-literate thief, obtaining a laptop or similar which may contain sensitive information. –  Liam McSherry Mar 13 '13 at 19:31
    
@LiamMcSherry Unless I'm missing something, are you using your application to some-how encrypt files on the client's machine? –  Adnan Mar 13 '13 at 19:45
    
Files are encrypted, and the client polls the server for the status of the machine, which is set via a web control panel. If the machine is "lost/stolen," the program deletes the encrypted files, as well as any files marked "sensitive" on the machine. Paraphrased slightly from the spec I have infront of me. –  Liam McSherry Mar 13 '13 at 20:27

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.