Proper password hashing
Locked
 
|
I have a question about login forms like this:
(html form) defaultAction: [self confirmLogin]; with: [(html heading) level3; with: 'Welcome to my site'. html bold: 'Enter login name:'. (html textInput) withValue: ''; callback: [:v | self login: v]. html bold: 'Enter password:'. (html passwordInput) callback: [:c | self password: ((SHA2 hash: c) asHexString asLowercase) ]. (html submitButton) text: 'Login!']. Isn't it the case that the password will be sent in plaintext up to the server, and only then will be hashed? Wouldn't one have to write Javascript to hash the password client-side, stuff it into a hidden form field, clear out the password field, and have >that< request sent up to the server? (Right now, I'd rather do that than put up an SSL server.) --Peter -- There's neither heaven not hell, save what we grant ourselves. There's neither fairness nor justice, save what we grant each other. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Proper password hashing
|
|
Peter,
If the attacker sniffs username/hash of a legit user, he can then add the hash to his own login form as a hidden field manually and gain access to your system. SSL is the only way to go here. Hope this helps, -Boris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter Kwangjun Suk Sent: 10 April 2011 15:20 To: Seaside - general discussion Subject: [Seaside] Proper password hashing I have a question about login forms like this: (html form) defaultAction: [self confirmLogin]; with: [(html heading) level3; with: 'Welcome to my site'. html bold: 'Enter login name:'. (html textInput) withValue: ''; callback: [:v | self login: v]. html bold: 'Enter password:'. (html passwordInput) callback: [:c | self password: ((SHA2 hash: c) asHexString asLowercase) ]. (html submitButton) text: 'Login!']. Isn't it the case that the password will be sent in plaintext up to the server, and only then will be hashed? Wouldn't one have to write Javascript to hash the password client-side, stuff it into a hidden form field, clear out the password field, and have >that< request sent up to the server? (Right now, I'd rather do that than put up an SSL server.) --Peter -- There's neither heaven not hell, save what we grant ourselves. There's neither fairness nor justice, save what we grant each other. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Proper password hashing
|
|
On Sun, Apr 10, 2011 at 2:36 PM, Boris Popov, DeepCove Labs
<[hidden email]> wrote: > If the attacker sniffs username/hash of a legit user, he can then add > the hash to his own login form as a hidden field manually and gain > access to your system. SSL is the only way to go here. Boris, thanks for the well meaning advice but that is just dead wrong. The way this is usually done is that a challenge bit-string is issued by the server, which is then hashed with the hash of the password. SSL is not the only way to go, though when it is working right, the security is very good. I'd rather not have the overhead now and login is enough for my purposes for now. This is the way login security worked on old Unix boxen when I was coding on them as an undergrad in the 80's. Have we as a field really forgotten all this stuff? --Peter -- There's neither heaven not hell, save what we grant ourselves. There's neither fairness nor justice, save what we grant each other. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Proper password hashing
|
|
Peter,
Even if you salt it, the attacker had sniffed the legit user's session key or cookie already. MITM FTW. Sent from my iPhone On 2011-04-10, at 19:23, "Peter Kwangjun Suk" <[hidden email]> wrote: > On Sun, Apr 10, 2011 at 2:36 PM, Boris Popov, DeepCove Labs > <[hidden email]> wrote: >> If the attacker sniffs username/hash of a legit user, he can then add >> the hash to his own login form as a hidden field manually and gain >> access to your system. SSL is the only way to go here. > > Boris, thanks for the well meaning advice but that is just dead wrong. > The way this is usually done is that a challenge bit-string is issued > by the server, which is then hashed with the hash of the password. > SSL is not the only way to go, though when it is working right, the > security is very good. I'd rather not have the overhead now and login > is enough for my purposes for now. > > This is the way login security worked on old Unix boxen when I was > coding on them as an undergrad in the 80's. Have we as a field really > forgotten all this stuff? > > --Peter > > -- > There's neither heaven not hell, > save what we grant ourselves. > There's neither fairness nor justice, > save what we grant each other. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Proper password hashing
|
|
http://codebutler.github.com/firesheep/
Sent from my iPhone On 2011-04-10, at 22:22, "Boris Popov, DeepCove Labs" <[hidden email]> wrote: > Peter, > > Even if you salt it, the attacker had sniffed the legit user's session key or cookie already. MITM FTW. > > Sent from my iPhone > > On 2011-04-10, at 19:23, "Peter Kwangjun Suk" <[hidden email]> wrote: > >> On Sun, Apr 10, 2011 at 2:36 PM, Boris Popov, DeepCove Labs >> <[hidden email]> wrote: >>> If the attacker sniffs username/hash of a legit user, he can then add >>> the hash to his own login form as a hidden field manually and gain >>> access to your system. SSL is the only way to go here. >> >> Boris, thanks for the well meaning advice but that is just dead wrong. >> The way this is usually done is that a challenge bit-string is issued >> by the server, which is then hashed with the hash of the password. >> SSL is not the only way to go, though when it is working right, the >> security is very good. I'd rather not have the overhead now and login >> is enough for my purposes for now. >> >> This is the way login security worked on old Unix boxen when I was >> coding on them as an undergrad in the 80's. Have we as a field really >> forgotten all this stuff? >> >> --Peter >> >> -- >> There's neither heaven not hell, >> save what we grant ourselves. >> There's neither fairness nor justice, >> save what we grant each other. >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Proper password hashing
|
|
In reply to this post by Peter Kwangjun Suk
Why? I mean why do that instead of salt-hashing it while relying on SSL for the client side?
On Apr 10, 2011, at 4:19 PM, Peter Kwangjun Suk wrote: > I have a question about login forms like this: > > (html form) > defaultAction: [self confirmLogin]; > with: > [(html heading) > level3; > with: 'Welcome to my site'. > html bold: 'Enter login name:'. > (html textInput) > withValue: ''; > callback: [:v | self login: v]. > html bold: 'Enter password:'. > (html passwordInput) > callback: [:c | self password: ((SHA2 hash: c) > asHexString asLowercase) ]. > (html submitButton) > text: 'Login!']. > > Isn't it the case that the password will be sent in plaintext up to > the server, and only then will be hashed? Wouldn't one have to write > Javascript to hash the password client-side, stuff it into a hidden > form field, clear out the password field, and have >that< request sent > up to the server? (Right now, I'd rather do that than put up an SSL > server.) > > --Peter > > -- > There's neither heaven not hell, > save what we grant ourselves. > There's neither fairness nor justice, > save what we grant each other. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Proper password hashing
|
|
In reply to this post by Peter Kwangjun Suk
2011/4/10 Peter Kwangjun Suk <[hidden email]>:
> I have a question about login forms like this: > > (html form) > defaultAction: [self confirmLogin]; > with: > [(html heading) > level3; > with: 'Welcome to my site'. > html bold: 'Enter login name:'. > (html textInput) > withValue: ''; > callback: [:v | self login: v]. > html bold: 'Enter password:'. > (html passwordInput) > callback: [:c | self password: ((SHA2 hash: c) > asHexString asLowercase) ]. > (html submitButton) > text: 'Login!']. > > Isn't it the case that the password will be sent in plaintext up to > the server, and only then will be hashed? Wouldn't one have to write > Javascript to hash the password client-side, stuff it into a hidden > form field, clear out the password field, and have >that< request sent > up to the server? (Right now, I'd rather do that than put up an SSL > server.) You should use a salt, probably the login in this case (doesn't address the sniffing). Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Proper password hashing
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
On Sun, Apr 10, 2011 at 9:21 PM, Boris Popov, DeepCove Labs
<[hidden email]> wrote: > Peter, > > Even if you salt it, the attacker had sniffed the legit user's session key or cookie already. MITM FTW. True that, but I think that most would bother, while a >plaintext password< is a bit too glaring a target. So something more a step more secure than plaintext is what I'm looking for, just to keep kiddies away from my dev server. I'll probably be implementing SSL eventually anyhow. --Peter -- There's neither heaven not hell, save what we grant ourselves. There's neither fairness nor justice, save what we grant each other. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |