?

Log in

No account? Create an account

Previous Entry | Next Entry

one time passwords

:does a dance of joy:

I understand! I understand! It all came clear to me in a flash, a splash, a gentle pitter patter of "OH DAMN, YEAH!"

See, I wanted to write a chat server/client, and... I didn't want to transmit plain text passwords. Right?

Right. (???)

okay. client connects to server, server challenges client with a unique phrase... client one-way-encrypts password with said phrase... server one-way-encrypts the local password with said phrase. and bam. :)

the one problem then is the server doesn't really have the password either. though that's not entirely a problem I guess. Everything's salted already... so the client just has to know how to salt, and then sends the salt encrypted by a OTP.

what encryption to use... salt again? might as well since it's already there... except salt only operates on two letters. so that wouldn't make a huge set of OTPs. maybe salt a salt a salt a salt a salt. I guess I need to do more reading to see if salting twice is any more secure than salting once. Or find some other way to do it.

Comments

( 7 comments — Leave a comment )
nibot
Oct. 9th, 2002 10:07 pm (UTC)
This is how, for example, APOP works. But since /etc/passwd only stores password hashes, it requires a separate database storing passwords in plaintext. This is fine if you don't need to use the passwords from /etc/passwd. The password hashes are generated using the crypt(3) library function, which provides 4096 different ways of hashing a given string. The only reason this is used is so that you can't "pre-hash" a list of words and then simply compare these to those passwords in /etc/passwd, which would make it easier to crack large password lists. When you talk about "salting a salt" and "encrypting two characters," I think you're extremely confused.

I think it's impossible to do what you're attempting, since there are only one-way functions involved. If all you have is a list of hashed passwords, and the client sends you hash(strcat(password,challenge)) then there's no way to verify that they match. But if you have the list of passwords, you can easily compute hash(strcat(password,challenge)) yourself.

You CAN do what you're trying to do using Public Key cryptography. Server generates a key pair K=(public,private) and sends the public key to the client. The client encypts the password with the public key and sends that to the server. The server deciphers this using the private key, recovering the password. Then the server applies the hash function and compares to /etc/passwd or whatever.

Just storing plaintext passwords on the server is probably the most direct thing to do and can be made as secure as general system security. You can use MD5 for the hash function, it's a good and standard thing. Otherwise there's the traditional Unix crypt() which is based on DES.
kaolinfire
Oct. 9th, 2002 10:15 pm (UTC)
okay, yes, I was being very vague and mixing my terms up some.

passwords are currently stored "crypt"ed... crypt uses 2 letters as a "salt" to crypt it. that salt is relatively safe to know (I presume), as they're in /etc/passwd. they can be brute forced, but it takes some time.

so I was thinking:

server has crypt(password)
server sends onetimekey
client responds with onteimekey(crypt(password)
server verifies onetimekey(crypt(password))

...

which makes the crypted password the password, essentially, for this purpose. which is kinda wacky, but... not a horrible thing, I think.

however, I'll look more into public/private key pairs. Hopefully they're not too hard to generate? I was kinda getting glazy-eyed reading RFC 1760 (S/Key)... but I think that's a function of RFCs. I was also just getting into reading about how to implement md5, because that's a good thing.

thanks. :)
nibot
Oct. 9th, 2002 10:30 pm (UTC)
That's not secure, because an evesdropper would get both the one time pad, and the OTP-encrypted password-equivalent.

That is the big problem with one-time-pads: it's just as difficult to deal with the OTP as it is the original plaintext.

Don't bother trying implement the encryption *algorithm* yourself, unless you want the exercise; it's hard to do right, and hard to do efficiently; and there are many good libraries already extant.

I advocate the APOP-style keep-plaintext-on-server, send challenge, reply with hash(password + challenge). It's easy to implement, secure, and functional.
kaolinfire
Oct. 9th, 2002 10:34 pm (UTC)
but the one time key would never be used or accepted again, so giving that much shouldn't be an issue, right?

nibot
Oct. 9th, 2002 10:41 pm (UTC)
It is an issue, because the eavesdropper can get exactly whatever it is you're trying to protect!

In this case, that's the hashed password, which has become "password equivalent". Someone could easily write a program to send the hashed password (instead of generating a password hash) and your system would be compromised. It amounts to "trusting the client" which is a big no-no.
nibot
Oct. 9th, 2002 10:49 pm (UTC)
This might work. I guess it's what you intended:

1. Server has crypt(password)
2. Server sends challenge to client
3. Client has crypt(password). Client computes crypt(challenge + crypt(password)), sends to server
4. Server computes that, too, and compares

In this, crypt(password) becomes "password equivalent", but it's never sent in plaintext across the link. The disadvantage is, if you're going to do this, then why bother storing crypt(password) on the server instead of just storing password ?
kaolinfire
Oct. 9th, 2002 10:55 pm (UTC)
sorry for using the wrong terms, and thanks MUCH for all the help with this. I hope it makes for a better system (actually, chances are nobody will try to hack this thing so nobody will run into the fact that I'm trying to do security "right and proper", but...) :)
( 7 comments — Leave a comment )

Latest Month

February 2016
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
2829     

Tags

Page Summary

Powered by LiveJournal.com
Designed by chasethestars