tag:blogger.com,1999:blog-33042626.post2268165013848849967..comments2008-04-29T13:31:40.134-07:00Comments on Paul Buchheit: Quick: Read this if you ever store password dataPaul Buchheithttp://www.blogger.com/profile/08521809827597159995noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-33042626.post-2581695384378385462007-09-30T18:42:00.000-07:002007-09-30T18:42:00.000-07:00Hi Paul,I'm Richie Hecker, serial entrepreneur, i ...Hi Paul,<BR/><BR/>I'm Richie Hecker, serial entrepreneur, i run bootstrapper.com and you can see who i am at www.richhecker.com. Anyway, someone got access to my gmail account and i (stupidly) fwd a lot of my business email through it and a lot of business contacts have it and i'm trying to figure out how to get it back. My secondary email address is old and no longer valid so i don't think there's anything i can do, also i can't afford to wait 5 days to get my email back, i'm wondering if you can help, i'm sorry for reaching out like this but my philosophy is when there's a problem, go right to the source so i figured i'd reach out to you. My account is rhecker@gmail.com and can prove it and provide a zillion industry references. please help me <BR/><BR/>Richie Hecker<BR/>347 385 7865<BR/>rich at bootstrapper.comFinancialManhttps://www.blogger.com/profile/04598938378052487389noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-34741422066366741382007-09-22T10:54:00.000-07:002007-09-22T10:54:00.000-07:00Ron: That doesn't work for me, if the passwords in...Ron: That doesn't work for me, if the passwords in the database are salted then the only difference it would make is that I then have to send 2 salts to the user agent.<BR/><BR/>Right now the server generates a random salt after it serves the login page (it's fetched through xmlhttp). The reason I did that is so that if someone intercepts the login on the network, then the hash is useless because the hash changes at every login attempt wether the password has changed or not.<BR/><BR/>I certainly recommend https over a scheme like this, using this method *and* https just makes no sense at all. Using https and another crypto challenge (beside login/pass) is best. I guess with these things it's a matter of what you can get away with though; When will you get complaints and how big a target are you?<BR/><BR/>jay: Thanks for the tip, I'll look into it when I'm doing something in Java :)<BR/>Hosters suck where I live though, they're still moving from PHP4 to PHP5 (ditto for FreeBSD). I wish there was a hoster in europe with, like, Lighttpd+php5 w/suhosin, apc and postgresql. (It's not that hard to configure a setup like that.) So the only chance for me to do a servlet is when I have to write an internal / business app.paulvghttps://www.blogger.com/profile/06797084021410691325noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-81428028921939687572007-09-22T10:18:00.000-07:002007-09-22T10:18:00.000-07:00I wish developers knew that storing passwords in p...I wish developers knew that storing passwords in plain text is bad. I've heard several stories of widely-used startup sites that store passwords unencrypted, and it makes me wonder how many other sites are doing the same thing. What if my bank does that? I have no way of knowing.Amithttps://www.blogger.com/profile/12159325271882018300noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-36112529643942054052007-09-21T08:51:00.000-07:002007-09-21T08:51:00.000-07:00paulvg: if the hashes are the result of a properly...paulvg: if the hashes are the result of a properly salted-password digest, then it will be much more difficult to do anything with them. That's the point. Rainbow tables are not effective against proper use of salt when digesting passwords.<BR/><BR/>It's your system though, so your call.<BR/><BR/>Cheers,<BR/>RonRon Forresterhttps://www.blogger.com/profile/14753736146970890841noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-46060411700756697732007-09-21T07:28:00.000-07:002007-09-21T07:28:00.000-07:00You may want to consider Acegi, now a subproject o...You may want to consider <A HREF="http://acegisecurity.org/" REL="nofollow">Acegi</A>, now a subproject of the Spring framework. They have a pretty mature auth' mechanisms, that allow for <A HREF="http://acegisecurity.org/guide/springsecurity.html#dao-provider" REL="nofollow">salts, password encoders</A>, and various data sources (in memory, jdbc, hibernate, etc).Jay Bosehttps://www.blogger.com/profile/03176537559779277355noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-73801882223910803642007-09-20T15:32:00.000-07:002007-09-20T15:32:00.000-07:00They can wreak havoc with the hashes too, only dif...They can wreak havoc with the hashes too, only difference is that they don't know the original plaintext password.paulvghttps://www.blogger.com/profile/06797084021410691325noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-60668954691698422462007-09-20T15:23:00.000-07:002007-09-20T15:23:00.000-07:00They don't necessarily have full access to the dat...They don't necessarily have full access to the database though -- it may be that a sql injection vulnerability exists such that they can only read the user table, in which case they now have names and passwords to login to the web site and wreak havoc.<BR/><BR/>Security is best applied in layers.<BR/><BR/>Cheers,<BR/>RonRon Forresterhttps://www.blogger.com/profile/14753736146970890841noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-33662040359626738132007-09-20T14:31:00.000-07:002007-09-20T14:31:00.000-07:00I already use sha256, but the problem is that in m...I already use sha256, but the problem is that in my web application, I send a fully random binary salt to the client (using a base64) with the length equal to a block in the used hash function (so for sha256 thats 64 bytes iirc). Then a javascript uses that salt and the hash of the password to create another hash. Then the server does this too, yadda yadda you get the idea.<BR/><BR/>If the database has a salt on it, then I'd need to send 2 salt values to the client. There's not much point to it other then to secure the database after it has been compromised. Which sounds like a weird idea to me anyway. In fact, why shouldn't they be stored in plain text? After all, if they've got acces to the database, they don't really need a password anyway. The only reason I can think of is that perhaps some users use a single password everywhere. But that's not my fault.paulvghttps://www.blogger.com/profile/06797084021410691325noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-23044239743571523032007-09-20T12:46:00.000-07:002007-09-20T12:46:00.000-07:00To say that a properly salted SHA-1 password diges...To say that a properly salted SHA-1 password digest is "not much better" than a plain-text password is really, really misleading. I can appreciate the gist of your post, which is don't take password storage lightly, and think you can come up with your own scheme.<BR/><BR/>I haven't looked at the code for bcrypt, but I would be very surprised, even based on the api snippet you show, if they are not simply salting and and digesting the password.<BR/><BR/>Rainbow tables are making this type of password storage less secure, but it's still many orders of magnitude stronger than plain-text.<BR/><BR/>Cheers,<BR/>rjf&Ron Forresterhttps://www.blogger.com/profile/14753736146970890841noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-58951422617183049862007-09-20T12:30:00.000-07:002007-09-20T12:30:00.000-07:00hum... salted + SHA2 then.hum... salted + SHA2 then.Anonymoushttps://www.blogger.com/profile/17002578166283757395noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-14604607919725888312007-09-19T10:24:00.000-07:002007-09-19T10:24:00.000-07:00Is SHA-1 really that easy to brute-force,currently...Is SHA-1 really that easy to brute-force,<BR/>currently (circa late 2007)?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33042626.post-74147118556840596652007-09-17T21:25:00.000-07:002007-09-17T21:25:00.000-07:00The (patented) state of the art in challenge-respo...The (patented) state of the art in challenge-response auth, SRP, doesn't require passwords stored reversably. It's a neat trick. But you have a good point; cleartext password storage is what was wrong with APOP, too.Thomas Ptacekhttps://www.blogger.com/profile/14479575601987181670noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-30539122459256263432007-09-17T16:10:00.000-07:002007-09-17T16:10:00.000-07:00Secure authentication is much more important than ...Secure authentication is much more important than secure password storage. That leads us to challenge-response methods and those usually make us store passwords in clear text anyway.<BR/><BR/>Btw, as far as I understand, linked article did it work wonderfully and became obsolete :) Nobody uses plain old DES crypt(3) in password hashes for a long time, in part due to the work authors of the paper did in OpenBSD.kappahttps://www.blogger.com/profile/10283564172364338483noreply@blogger.com