Re: Plaintext passwords?

[cacharbe]

I know I'm coming late to the dance with this, but I've been giving it some thought. When we speak of security, we are usually talking about one or two different things; authentication and encryption. The http protocol isn't really designed for security, it is designed for functionality. Security is left to the implementor.

Putting aside https for the moment (which really is the best implementation of http when it comes to both of these topics) we need to look at what we can do to fulfill both of these points. In the case of a login, we are actually in the process of trying to authenticate our user, which means there isn't a trust system in place between the two parties.

My thought about this would be that when a user first subscribes to our system, they are required to provide they're public key. Also, the monks public key is provided on the site. Now, when someone logs in, they first encrypt their pass-phrase (We're talking security here, so let's go all the way) with the monks public key, insert it into the pass-phrase text area and submit.

PM has its private key, decrypts the pass-phrase and registers it. And, of course, monks must repeat this cycle if they must login. Of course we can still use our current cookie method of remembering who we are to limit the need for this. Beware, however, if we are at a location that doesn't have a tool for encryption, we won't be able to login. If a pass-phrase is lost, a new one can be generated and emailed to the monk using their public key. The system is complete.

Another way would be to write an encryption method (using the above mentioned key structure) completely in JavaScript, send the PM public key in the client side scripting. OnSubmit, encrypt the pass-phrase, set one of your inputs (hidden or otherwise) to the encrypted password and away you go.

Sounds trivial, but I'm not sure I would want to try and write those algorithms in JavaScript of VBScript. *BLECH*

This brings me back to https. This protocol has the two pieces of security that I mentioned above. The authentication portion of https is a safeguard against some site saying they are PM when they're really not and stealing whatever informaiton we are sending to one another. The simplist method of encrypting passwords would be to implement the login only in https without a third party certificate. All we are truly talking about here is encrypting passwords and sending them securely, not authenticating one or both of the parties involved. On most webservers you can allow the server to generate it's own certificate for the sake of encryption, and only if we were going to implement a shopping cart or something similar would the need for a third party cert really be necessary.

Those are just some thoughts I've had about this topic, your mileage may vary, this offer only good to the first ten callers, some restrictions may apply.

C-.

[no_slogan]

If a pass-phrase is lost, a new one can be generated and emailed to the monk using their public key.

That would be really cool except for one little problem: what happens if I forget the password to my private key? I used to do that regularly, because I didn't decrypt messages very often.

Now, when someone logs in, they first encrypt their pass-phrase with the monks public key, insert it into the pass-phrase text area and submit.

You need to prevent someone from capturing and reusing my encrypted password, too. See my comment on nonces elsewhere in this thread.

Of course we can still use our current cookie method of remembering who we are to limit the need for this.

If you do this, my cookie essentially becomes my password, because anyone who has my cookie can make the system think he's me. Cookies are stored in plaintext on the user's computer. Cookies are sent across the network in plaintext. Not good for security.

Beware, however, if we are at a location that doesn't have a tool for encryption, we won't be able to login.

I think this is a deal-breaker for most web apps.