Username and Password protecting
Moderator: General Moderators
Username and Password protecting
Hi,
I just started learning PHP and I have a some questions to ask, ( it might not need to be here, maybe in theory forum ):
1.Whats the point of encrypting a users password?
how is it going to get discovered? just in case somebody gets a look at the Database?
2. MD5 ( or any 1-way encryption ) has rainbow tables.
If I add a salt, am I now all good is there something more?
3. Is there a need to encrypt user-names ( not just their passwords ) ?
4.If cookies can be altered by users, what exactly can I do so that they cant access someone else's account?
If I use a 1-way encryption, thats no good, I would have to add information in the cookie containing the user name.
If I use a 2-way encryption, thats no good either, cause it means they can find the encryption used, then encrypt a diffrent user name to that, and put that in the cookie.
so whats the solution?
A heads-up thanks to all that try to help, I hope to advance in PHP scripting and stay here for a long time.
Trath
I just started learning PHP and I have a some questions to ask, ( it might not need to be here, maybe in theory forum ):
1.Whats the point of encrypting a users password?
how is it going to get discovered? just in case somebody gets a look at the Database?
2. MD5 ( or any 1-way encryption ) has rainbow tables.
If I add a salt, am I now all good is there something more?
3. Is there a need to encrypt user-names ( not just their passwords ) ?
4.If cookies can be altered by users, what exactly can I do so that they cant access someone else's account?
If I use a 1-way encryption, thats no good, I would have to add information in the cookie containing the user name.
If I use a 2-way encryption, thats no good either, cause it means they can find the encryption used, then encrypt a diffrent user name to that, and put that in the cookie.
so whats the solution?
A heads-up thanks to all that try to help, I hope to advance in PHP scripting and stay here for a long time.
Trath
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: Username and Password protecting
"rather have it and not need it...". Rainbow tableTrath wrote:1.Whats the point of encrypting a users password?
how is it going to get discovered? just in case somebody gets a look at the Database?
Scratch md5() off your list, it's no good (as many forum visitors will probably tell you). You can add a pepper as well.Trath wrote:2. MD5 ( or any 1-way encryption ) has rainbow tables.
If I add a salt, am I now all good is there something more?
viewtopic.php?t=62782
Why make it 50% easier for an attacker to access your account?Trath wrote:3. Is there a need to encrypt user-names ( not just their passwords ) ?
I'd have to say add a few more checks to the system. Although these aren't foolproof you could go for IP address checking? My knowledge on cookie security aren't as great as it probably should beTrath wrote:4.If cookies can be altered by users, what exactly can I do so that they cant access someone else's account?
If I use a 1-way encryption, thats no good, I would have to add information in the cookie containing the user name.
If I use a 2-way encryption, thats no good either, cause it means they can find the encryption used, then encrypt a diffrent user name to that, and put that in the cookie.
so whats the solution?
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Re: Username and Password protecting
Thank you very much, that article you gave me was really good and "knowledge-adding".
It really does seem the best way to hash is salt and pepper.
However, to the username point, most forums ( vBulletin, PHPBB ) and Systems dont ask for a username AND displayname.
Have they thought of something I haven't, or do they just not encrypt the username?
still waiting for a cookie answer ^^
It really does seem the best way to hash is salt and pepper.
However, to the username point, most forums ( vBulletin, PHPBB ) and Systems dont ask for a username AND displayname.
Have they thought of something I haven't, or do they just not encrypt the username?
still waiting for a cookie answer ^^
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Username and Password protecting
Firstly, you seem to be confusing hashing (1 way) and encryption (2 way)Trath wrote:Thank you very much, that article you gave me was really good and "knowledge-adding".
It really does seem the best way to hash is salt and pepper.
However, to the username point, most forums ( vBulletin, PHPBB ) and Systems dont ask for a username AND displayname.
Have they thought of something I haven't, or do they just not encrypt the username?
still waiting for a cookie answer ^^
I'm not understanding you here. 99% of authentication software will simply ask you for a username/password combo to verify if the password hash equals the hash of the specified user. There is no benefit to hashing your username, since hashing is one way and you'll lose the original value. If you want to encrypt your usernames, which may have minor benefits in terms of protecting from data theft, then your database authentication operations will become significantly slower and more complicated. Basically most systems won't bother. Credit card information for instance we may be concerned about though
So can you elaborate on what you are trying to ask?
As far as cookies so, you generally don't want to store anything security related in them. Simply store the session identifier in your cookie (which PHP handles automatically), and make sure you regenerate_session_id() after any significant operation to prevent session fixation (session hijacking).
Re: Username and Password protecting
Yeah I didnt realize they mean 1 or 2 way, I thought they have exactly the same meaning.John Cartwright wrote: Firstly, you seem to be confusing hashing (1 way) and encryption (2 way)
Yeah but the point of hashing the username is that now the Hacker/Cracker has not 1, but 2 things to find. ( each with 8593085902830952839057450734057346709346749 options )John Cartwright wrote: I'm not understanding you here. 99% of authentication software will simply ask you for a username/password combo to verify if the password hash equals the hash of the specified user. There is no benefit to hashing your username, since hashing is one way and you'll lose the original value. If you want to encrypt your usernames, which may have minor benefits in terms of protecting from data theft, then your database authentication operations will become significantly slower and more complicated. Basically most systems won't bother. Credit card information for instance we may be concerned about though
So can you elaborate on what you are trying to ask?
I was asking, is there a way to hash the username and still have it unhashed, but I guess thats a dumb question
So you say to leave the username alone, eh?
The only thing I dont understand, why would encrypting the username make database authentication operations significantly slower?
Obviously it cant be as fast as plain-text, but it wouldn't make it "a lot" slower. I mean when you compare a hashed password, it's like the same thing?
Unless your saying its because I would have to search for the encrypted username name.
I just thought though, I would have to de-encrypt the username each time I want to show it as plain-text, that be a lot more slower each page, each time.
As far as cookies so, you generally don't want to store anything security related in them. Simply store the session identifier in your cookie (which PHP handles automatically), and make sure you regenerate_session_id() after any significant operation to prevent session fixation (session hijacking).[/quote]
Ok ill learn more about cookies and sessions to understand what you said
Re: Username and Password protecting
Trath, why would you encrypt the username? You're correct though comparing two hashes is no faster/slower than comparing the password itself.
The general way to keep this really secure is to generate a random salt and hash it in with the password, send the hashed password & the salt to the server. Or you could hash the password, append a salt to that string and then hash that, that way you can use a salt & only store a hash on the server side.
The general way to keep this really secure is to generate a random salt and hash it in with the password, send the hashed password & the salt to the server. Or you could hash the password, append a salt to that string and then hash that, that way you can use a salt & only store a hash on the server side.
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: Username and Password protecting
It's not a dumb question just uninformed (no offenceTrath wrote:I was asking, is there a way to hash the username and still have it unhashed, but I guess thats a dumb question
Im speaking from working on systems that doesn't require a username to be displayed but instead having a 'display name' for that purpose. It looks like a question of preference because I don't know any statistics on whether having 2 hashed values is safer than just 1 (or vice versa).
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Re: Username and Password protecting
hmm, I forgot I wanted to ask something more 
1.If the pepper ( custom user salt ), is saved in the Database, then whats the point? If somebody gets hold of the database, he can see the custom-user?
Just so that 2 user names dont have the exact same password, and if somebody hacks a users password, he cant compare to see if somebody else has the same password?
or is it so that a hacker would have to add the custom salt on the rainbow table each time, again and again, so with a bunch of diffrent user-salts, its like 99999999999999 more Computer Power needed?
Even if I do use a custom user-salt, how do I choose/create it?
Just a function/loop that creates a random 10-letter word?
2. How do all Hash's work?. I mean, obviously they change the plain-text into %@#%#$ you cant understand, but the reason im asking is:
If a hash turns a Password to 128 characters, does that mean the salt has to be short?
I mean, theoretically, wouldn't
someHash(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaPassword);
==
someHash(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
?
since on the field, they dont produce the same result, it got me asking how a hash works?
how does it take in ALL the characters of the plain-text into play?
Social_Experiment :
so you think i'm good hashing just the password, and not the username?
Josh:
If I encrypt the username, it means that if perhaps someone gets a hold on the database through some hole in the script, and he wants to hack the username Bobbie, cause he hates him, hes not going to find the username on the database.
This I believe gets me to the question:
Can an encryption be unencrypted without knowing which encryption it is?
1.If the pepper ( custom user salt ), is saved in the Database, then whats the point? If somebody gets hold of the database, he can see the custom-user?
Just so that 2 user names dont have the exact same password, and if somebody hacks a users password, he cant compare to see if somebody else has the same password?
or is it so that a hacker would have to add the custom salt on the rainbow table each time, again and again, so with a bunch of diffrent user-salts, its like 99999999999999 more Computer Power needed?
Even if I do use a custom user-salt, how do I choose/create it?
Just a function/loop that creates a random 10-letter word?
2. How do all Hash's work?. I mean, obviously they change the plain-text into %@#%#$ you cant understand, but the reason im asking is:
If a hash turns a Password to 128 characters, does that mean the salt has to be short?
I mean, theoretically, wouldn't
someHash(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaPassword);
==
someHash(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
?
since on the field, they dont produce the same result, it got me asking how a hash works?
how does it take in ALL the characters of the plain-text into play?
Social_Experiment :
so you think i'm good hashing just the password, and not the username?
Josh:
If I encrypt the username, it means that if perhaps someone gets a hold on the database through some hole in the script, and he wants to hack the username Bobbie, cause he hates him, hes not going to find the username on the database.
This I believe gets me to the question:
Can an encryption be unencrypted without knowing which encryption it is?
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: Username and Password protecting
IMHO, i'd say hash the username, the other posters have valid points regarding not hashing usernames but if i had a choice, i would hash it.Trath wrote:Social_Experiment :
so you think i'm good hashing just the password, and not the username?
As josh said,
josh wrote:You're correct though comparing two hashes is no faster/slower than comparing the password itself.
The attacker might have the pepper but he doesn't have the method to determine the hash. And if the attacker has accessed your database it means your system is much more compromised so your hashed (then useless) login details will be of little consequence. If you are malicious, why search for login information if you can just truncate or drop the table? In answer to the second point, that's why you have different usernames, now you have 2 values, that has to be match before a user is authenticated.Trath wrote:1.If the pepper ( custom user salt ), is saved in the Database, then whats the point? If somebody gets hold of the database, he can see the custom-user?
Just so that 2 user names dont have the exact same password, and if somebody hacks a users password, he cant compare to see if somebody else has the same password?
Something like that. Yeah you can create a function, just remember: If you keep creating random salts, you will have to make sure your password is hashed with this new salt each time.Trath wrote:or is it so that a hacker would have to add the custom salt on the rainbow table each time, again and again, so with a bunch of diffrent user-salts, its like 99999999999999 more Computer Power needed? Even if I do use a custom user-salt, how do I choose/create it? Just a function/loop that creates a random 10-letter word?
You'd have to google this, the process of hashing is intricate. I don't think the length of the salt matters, at the end of the hash your value is still converted to 128 (or whatever) amount of characters.Trath wrote:2. How do all Hash's work?.
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Re: Username and Password protecting
The way I was discussing you do this. I'm writing md5() but use a more secure function. I'm using + to indicate concatenation.
first_hash = md5(PLAIN TEXT + SALT ONE)
// this goes into the database, salt one is the user's username for example, or a random string is better. The salt is in plain text
// user goes to login, the salt is sent over https
// user enters their password, together with salt one, first_hash is calculated client side but not yet sent
// client generates a new, SALT TWO and hashes that in with first_hash (two layers of hashing). Call this second_hash.
// second_hash is posted to the server along with salt two. Salt two is stored in a file so the request cannot be replayed by an attacker.
// server takes salt TWO and second_hash, looks at first_hash in DB. then does this:
if( second_hash == md5( first_hash + SALT_TWO ))
So as you can see, you are applying salting at all levels to make brute force/dictionary harder. You also disallow an attacker from simply recording & playing back an http request if he's packet sniffing. You send nothing over the wire that is of any use, because SALT_TWO is no longer any good, and neither is second_hash (both are invalidated after the first use). You force your users to change their passwords more frequently than you empty the "used hashes" table, and you store & invalidate their last 5 passwords (don't let them change their password to any password they've used for their last 5 passwords)
Even with this level of security someone could easily man in the middle attack. All they'd have to do is intercept the original request, modify it's source IP so they receive the response instead of you. After they receive the response they forward it back to you. They couldn't replay the attack but they could grab the session ID and become authenticated. For this reason a secure system always re-prompts for the password prior to any serious actions. Its scary how many financial institutions don't even do this though, but my bug tracker & forum software does... wtf lol
first_hash = md5(PLAIN TEXT + SALT ONE)
// this goes into the database, salt one is the user's username for example, or a random string is better. The salt is in plain text
// user goes to login, the salt is sent over https
// user enters their password, together with salt one, first_hash is calculated client side but not yet sent
// client generates a new, SALT TWO and hashes that in with first_hash (two layers of hashing). Call this second_hash.
// second_hash is posted to the server along with salt two. Salt two is stored in a file so the request cannot be replayed by an attacker.
// server takes salt TWO and second_hash, looks at first_hash in DB. then does this:
if( second_hash == md5( first_hash + SALT_TWO ))
So as you can see, you are applying salting at all levels to make brute force/dictionary harder. You also disallow an attacker from simply recording & playing back an http request if he's packet sniffing. You send nothing over the wire that is of any use, because SALT_TWO is no longer any good, and neither is second_hash (both are invalidated after the first use). You force your users to change their passwords more frequently than you empty the "used hashes" table, and you store & invalidate their last 5 passwords (don't let them change their password to any password they've used for their last 5 passwords)
Even with this level of security someone could easily man in the middle attack. All they'd have to do is intercept the original request, modify it's source IP so they receive the response instead of you. After they receive the response they forward it back to you. They couldn't replay the attack but they could grab the session ID and become authenticated. For this reason a secure system always re-prompts for the password prior to any serious actions. Its scary how many financial institutions don't even do this though, but my bug tracker & forum software does... wtf lol
Re: Username and Password protecting
umm, that was basicly half alien talk to me 
I"ll have to read it a couple times to fully understand what you said.
the one thing I have a problem with is:
did you just say even data transmitted over https ( ssl ) can be intercepted???!%@#%@#$%^#
I"ll have to read it a couple times to fully understand what you said.
the one thing I have a problem with is:
did you just say even data transmitted over https ( ssl ) can be intercepted???!%@#%@#$%^#
Re: Username and Password protecting
Yes data sent over https can be intercepted. This is more likely to happen if you are on an unsecured wireless network, or large LAN, as the hacker must be within physical proximity to you, or the ISP.. The steps I talked about basically boil down to these two rules
1 - anyone can theoretically forge an http request to look like the victim's IP was the source, for example a forged "transfer funds to bank account" request. Solution = require the password as part of the request
2 - anyone can theoretically record & play back any traffic. More advanced tools allow scripted modifications of all traffic passing thru the filter. (For example, making every request for an image respond with the hacker's jpeg... another example would be recording a money transfer request for $1 and simply playing it back 1,000 times, if the server code was too naive the hacker wins. Only a hash code should be sent over the network, and it should use a random salt & block replay attacks)
There's also things like CSRF attacks,(hacker gets victim to click a link that makes his browser send a request), re-prompting for the password, and using a "token" that must be validated with all POST requests solve this. There's also XSS, for example an attacker could insert Javascript to log keystrokes, record the password in plaintext, and send the payload (logged keystrokes) to his server.
1 - anyone can theoretically forge an http request to look like the victim's IP was the source, for example a forged "transfer funds to bank account" request. Solution = require the password as part of the request
2 - anyone can theoretically record & play back any traffic. More advanced tools allow scripted modifications of all traffic passing thru the filter. (For example, making every request for an image respond with the hacker's jpeg... another example would be recording a money transfer request for $1 and simply playing it back 1,000 times, if the server code was too naive the hacker wins. Only a hash code should be sent over the network, and it should use a random salt & block replay attacks)
There's also things like CSRF attacks,(hacker gets victim to click a link that makes his browser send a request), re-prompting for the password, and using a "token" that must be validated with all POST requests solve this. There's also XSS, for example an attacker could insert Javascript to log keystrokes, record the password in plaintext, and send the payload (logged keystrokes) to his server.
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: Username and Password protecting
Wikipedia on HTTP Secure wrote:The main idea of HTTPS is to create a secure channel over an insecure network
But wouldn't the data sent be encrypted ? Assume i sent my password over a https connection wouldn't the person intercepting it (i'm guessing man-in-the-middle attack here) receive an encrypted value?josh wrote:Yes data sent over https can be intercepted.
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Re: Username and Password protecting
from what I understood, he saying it can be intercepeted on a Wi-Fi, like between the Computer to the Router, or between the Router to the ISP.social_experiment wrote:Wikipedia on HTTP Secure wrote:The main idea of HTTPS is to create a secure channel over an insecure networkBut wouldn't the data sent be encrypted ? Assume i sent my password over a https connection wouldn't the person intercepting it (i'm guessing man-in-the-middle attack here) receive an encrypted value?josh wrote:Yes data sent over https can be intercepted.
Any way, josh, could you please explain the steps you recommended, more simply ( apologies for my slow brain )
Try to specify what is done by Javascript, Taken out of the DB, sent to the DB etc.. please.
BTW
how exactly do I hash with Javascript? let's say i'm using MD5 or SHA256 ?
Javascript has built-in functions, or do I import some library?
Thanks for all the help,
Trath
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: Username and Password protecting
Yip, i got that part but HTTPS does this ...provide encrypted communication and secure identification of a network web server so if the data is intercepted, it should be encrypted?Trath wrote:from what I understood, he saying it can be intercepeted on a Wi-Fi, like between the Computer to the Router, or between the Router to the ISP.
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering