0

I would like to at first be clear that this is for poor site owners who can't afford the SSL option but require logins to their site, potentially from a public kiosk, and need a secure method of allowing such. All I'm looking for is a public vetting of the process I have drawn up, if there are any attacks I may have missed that this process allows, and any foreseeable road bumps that it may introduce.

The process for signing up is thus:

  • User arrives at page, and login form is populated with the server's public key, and a nonce.
  • User enters password into form (and other identifying details). Password and nonce are combined and pushed through a key-derivation function
  • Using derived private key and server pubic key, encrypt password and send back ad-hoc client public key and encrypted password (and requisite identifying details).
  • Using client public key and server private key, decrypt password, generate salt, shove both through slow hash and store result.

The process for logging in would then be:

  • user arrives, receiving nonce and server's public key.
  • user enters username/password combo. Like before, nonce and password generate key pair
  • encrypt password with server public key, and generated private key, delete private, then send over client public, encrypted password, and username
  • server side, decrypt with server private and client public, grab salt corresponding to username, slow hash salted password, verify against database and continue login if all is well.

My main worry is that the use of the password to generate they key pair introduces a vulnerability in that if the ad-hoc public key sent over the wire can be used to reverse engineer into the nonce/password combination that generated they key pair, or even worse be used to somehow create the private key to decrypt the password if the derivation function is not strong enough. Are these legitimate concerns, and should this option even be on the table?

Mike S
  • 404
  • 2
  • 11
  • 4
    you can create your own self signed SSL certificate. –  Aug 27 '12 at 14:28
  • 1
    Without SSL you can protect against passive attacks, but you have no chance against active attacks(assuming a web application). – CodesInChaos Aug 27 '12 at 15:45
  • 2
    Your entire process would still be sent in plaintext, which means among other things, a simple session/cookie attack could be used. Just look up Firesheep. – Ramhound Aug 27 '12 at 15:47
  • 4
    The worst security mistake you can possibly make is trying to reinvent the wheel. For the love for all that is holy, use SSL. – rook Aug 27 '12 at 16:16
  • http://security.stackexchange.com/questions/17979/is-sending-password-to-user-email-secure – LolaRun Apr 07 '14 at 14:58

2 Answers2

7

In short: Just go to startssl.com and get your SSL certificate for free.

The protocol is not specific enough. If you aim to implement this yourself, you will likely introduce flaws in the signing and encryption steps. How are users going to validate the server's public key here? Do you expect them to compare hex-digits?

You also seem to assume that clients and servers can do custom computation steps, which is not typically the case on the Internet terminals you target. You may consider using the Secure Remote Passwort Protocol (SRP) in this case: trustedhttp.org

pepe
  • 3,536
  • 14
  • 14
6

Your method is trivially vulnerable to a Man in the Middle (MitM) attack. There are two benefits of using SSL:

  1. Sensitive traffic over the wire is sent encrypted (which your method effectively accomplishes) and

  2. you can cryptographically verify that you are going to the right website and not a fake version of the website. (Again note the URL in the address bar or IP address is not necessarily trusted if the routing was somehow altered).

Its relatively easy for an attacker to reroute traffic from some location to a page they control. However, they can't do this seemlessly for SSL websites as they don't have the SSL private key. So the correct way to do it is a free CA-signed SSL certificate.

The next best thing is to use HTTP digest authentication which implements a nonce signing process in a similar way to your scheme (though uses MD5 - a rather poor hash function; though that's probably the least of your worries with this method). This is implemented in the web browser (so its not trivial for an attacker to fake the same login screen while altering the backend). However, note for various UX reasons beyond just weaker security than SSL (all traffic other than passwords is plaintext and a complicated MitM is difficult but still possible), I don't recommend HTTP digest.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161