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?