Has anyone implemented this script over a nonsecured connection and implemented methods so that the passwords are not sent using plain text?
4 posters
Using PHP Login System without SSL
chill- Number of posts : 1
Registration date : 2008-02-08
Linchpin311- Number of posts : 220
Age : 38
Localisation : Long Island
Registration date : 2007-05-14
yes, i believe i have.Has anyone implemented this script over a nonsecured connection
not really sure what you mean by this??and implemented methods so that the passwords are not sent using plain text
Admin- Admin
- Number of posts : 18
Registration date : 2007-05-12
Hi there, the first thing I'd do is protect the stored passwords (in case someone was snooping in your database). I just explained this to someone, here:
http://www.webmasterworld.com/forum48/1025.htm
then, like you allude to in your post, I'd protect transmition of the passwords. using SSL is obviously ideal, but here is a simple way I came up with that can protect the password:
When the user types their username and password in the form, use javascript to "md5" the password when the user hits submit, and then submit the md5 hash. An intruder looking for the transmission of passwords over an unsecured connection would see the "md5" of the password rather than the actual password. Search google for "javascript md5" to get started.
PROS: this protects the password itself.
CONS: the intruder could still use the md5 hash of the password to login as the user. But they at least wouldn't know the user's actual password, since md5 is a one-way deal.
sources here
http://www.webmasterworld.com/forum48/1025.htm
then, like you allude to in your post, I'd protect transmition of the passwords. using SSL is obviously ideal, but here is a simple way I came up with that can protect the password:
When the user types their username and password in the form, use javascript to "md5" the password when the user hits submit, and then submit the md5 hash. An intruder looking for the transmission of passwords over an unsecured connection would see the "md5" of the password rather than the actual password. Search google for "javascript md5" to get started.
PROS: this protects the password itself.
CONS: the intruder could still use the md5 hash of the password to login as the user. But they at least wouldn't know the user's actual password, since md5 is a one-way deal.
sources here
Linchpin311- Number of posts : 220
Age : 38
Localisation : Long Island
Registration date : 2007-05-14
ya know, PHP has got md5() already built in (no need to install additional libraries). i agree with you 100% with everything else, but why complicate the script with a long complicated javascript function when PHP will do the exact same thing with much less overhead?
Fred-Eric- Number of posts : 63
Registration date : 2007-05-13
OUps it was this idea that I would like to bring up
However, I think the Javascript encryption would not be a bad way to go, and I think it would be pretty darned safe.
- The server generates a random key and implements this key into the Javascript custom encryption code. This key is used on the server side as well, so they must match.
- This function is used on the user's password on submit and sent back to the server.
- The server retrieves a plain-text version of the password (potential security risk, though securing the database would be the best bet, or using reversible encryption on the stored password) from a database and encrypts it using the same function and the same key, but they key that it generated, not the key as determined by the client. This way, someone trying to hack the system cannot use an arbitrary key, they must use the one created by the server.
However, I think the Javascript encryption would not be a bad way to go, and I think it would be pretty darned safe.
- The server generates a random key and implements this key into the Javascript custom encryption code. This key is used on the server side as well, so they must match.
- This function is used on the user's password on submit and sent back to the server.
- The server retrieves a plain-text version of the password (potential security risk, though securing the database would be the best bet, or using reversible encryption on the stored password) from a database and encrypts it using the same function and the same key, but they key that it generated, not the key as determined by the client. This way, someone trying to hack the system cannot use an arbitrary key, they must use the one created by the server.
Admin- Admin
- Number of posts : 18
Registration date : 2007-05-12
Password are freely viewable over the internet, an ca be skimmed easily. Public/private key encryption helps out by creating an encrypted code at the time the user wants to log in.
Two key are invloved in this process. The password is the private key and the public key is a random string sent from the server. here's how it works: Say the password is banana. When the user logs in, that password could simply be sent, using the GET or POSt method, to the server wich expose it publicily. That means malicious persons could skim it and use it to lo in themselves.
However, you could change that exposure cleverly at login time by having the code on the server send a random text string, say abcdefg. Then you combine the password and the random string to get, for exemple bananaabcdefg. Next, you can use an algorithm, such as MD5 algorithm, to encrypt the resulting string, bananaabcdefg. That gives you a string of bytes that you can send to the server.
That string of bytes may be skimmed as well, but won't do malicious people much good because the next time they try to log in, the random string will have changed, so the string of bytes they've skimmed won't work.
It's not a perfect scheme -- especially if the malicious entity can read the random string public key and figure out how it's used but it does provide some measure of protection.
How to modified the curent login script to reflect this idea.
to come....
Two key are invloved in this process. The password is the private key and the public key is a random string sent from the server. here's how it works: Say the password is banana. When the user logs in, that password could simply be sent, using the GET or POSt method, to the server wich expose it publicily. That means malicious persons could skim it and use it to lo in themselves.
However, you could change that exposure cleverly at login time by having the code on the server send a random text string, say abcdefg. Then you combine the password and the random string to get, for exemple bananaabcdefg. Next, you can use an algorithm, such as MD5 algorithm, to encrypt the resulting string, bananaabcdefg. That gives you a string of bytes that you can send to the server.
That string of bytes may be skimmed as well, but won't do malicious people much good because the next time they try to log in, the random string will have changed, so the string of bytes they've skimmed won't work.
It's not a perfect scheme -- especially if the malicious entity can read the random string public key and figure out how it's used but it does provide some measure of protection.
How to modified the curent login script to reflect this idea.
to come....
|
|
|