![]() |
How important is security on your website scripts to you?
Do you mind if the password for the admin areas of your scripts is sent to the server in plaintext or would you prefer something where, for instance, the server sends you a random string when you login, which is combined with the password you enter for a hahahahahahahahahaha md5-hash of the combination of both, which is then checked against a serverside md5-hash of both? (in other words, your password isn't sent in plaintext, which gives more security)
|
I take it this means you people don't care?
|
hahahahahaha = javascript by the way
|
Well I think most users would prefer a script as secure as possible for passwords etc. So md5-hash while not bullet proof certainly cant hurt and I would think is much better than just launching the password in plain text.
|
Quote:
What happens is the following (severely simplified): A person wants to login The server registers a session, containing the session id, the ip address of the user, the random variable which is used in the hash and the md5 hash of the password/variable (and other stuff like time of death etc) The user gets the random variable, which is used with the password for the generation of the md5 hash... uses JS, so the server doesn't have to do anything The md5 hash is verified against the md5 hash, user gets the md5 hash and the session id in a cookie Not bulletproof, and not as good as using ssl, but a hacker needs the session id, the md5 hash and the user's ip to get in. Also, the whole thing dies as soon as the user logs out or the session expires. So, he needs to do a bunch of stuff and is in a big hurry... and there is nothing he can do against the login stuff dying quickly :glugglug |
Here I am, all excited by introducing a new security standard for the scripts which control our income, and nobody is interested... *sigh*
|
on small, custom scripts i dont give a shit
toooo unimportant to pay extra cash for security |
Quote:
|
Note to programmers who want to implement something like this: Since nothing residing on the server should give a hacker enough info to login, you'll actually have to use a triple md5 for the value in the session database.
Here's a quick overview of the protocol: x = the password submitted by the user y = the random variable the server has md5(z) stored in the passwords database table, where z is the real password (1) user requests login page (2) server creates a random variable, y - server saves md5(md5(md5(z) + y)) - server sends y to the user (3) user enters password, x, and receives the random variable, y - user calculates md5(md5(x) + y) (4) user sends the result of md5(md5(x) + y) (5) server receives the result of md5(md5(x) + y) - server calculates md5(md5(md5(x) + y)) - server compares the result of md5(md5(md5(x) + y)) to the saved result of md5(md5(md5(z) + y)) There is still the danger of eavesdropping, but that will only reveal the result of md5(md5(x) + y), not x. It will be valid for a short while (although the ip is ofcourse also saved and checked), but when it dies a hacker will lose access. And, like with standard protection, the database being compromised will not mean a hacker gets any useful login info... unless ofcourse the hacker gets write access, but then you're screwed anyway. |
All times are GMT -7. The time now is 03:11 PM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123