tag:blogger.com,1999:blog-4110180.post113923720342990660..comments2023-06-20T05:31:24.545-07:00Comments on Tapestry Central: Why store passwords in the database?Anonymoushttp://www.blogger.com/profile/04486596490758986709noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-4110180.post-66634709732720430902009-06-12T12:30:09.084-07:002009-06-12T12:30:09.084-07:00I think its your comfort level. I don't think ...I think its your comfort level. I don't think anyone should be comfortable with passwords in plaintext, or with a simple two-way cipher (i.e., something like rot13). But if you are worried about real infiltration, not casual, yes there are a lot of options that are more secure.Anonymoushttps://www.blogger.com/profile/04486596490758986709noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-49327673247221285832009-06-12T11:28:30.840-07:002009-06-12T11:28:30.840-07:00don't use MD5, use salted SHA-1. use /dev/uran...don't use MD5, use salted SHA-1. use /dev/urandom for salt.<br />And even more: use 8192 iterations of SHA256, with additionall counter and salt in each step. It is still fast to login if you know good password, but makes bruteforce attack much harder. There are ways even better like bcrypt or scrypt (amazing one). One can also use SRP protocol, which is even safer, but is harder to implement and needs some tricks on client side (it uses big integer modular arithmetic), but it works and is VERY seucre even over unencrypted channels.Witek Barylukhttps://www.blogger.com/profile/12428843843234198274noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139671468196095262006-02-11T07:24:00.000-08:002006-02-11T07:24:00.000-08:00Anonymous, I'm not sure I understand the question....Anonymous, I'm not sure I understand the question. If you're doing a webmail app, then that is only a frontend for some IMAP store typically, in which case that IMAP store is responsible for the authentication of the user. The application would only be a user interface for that underlying service.<BR/><BR/>I was referring to the case when YOU are in charge of the actual application, and have a choice with regard to where to store the password. In which case the answer should be: don't.<BR/><BR/>But preferably I would even take it one step further: don't implement user authentication at all! Instead write the app as a portlet and rely on the portal implementation for authentication. In our portal product we support many different kinds of authentications, like certificates and SMS logins and things like that. It would be way way too costly I think if each app tried to keep up with the different kinds of authentication schemes that are available out there. By delegating that to the portal you just avoided a major problem. That is, given that you have access to a portal platform that you like and which has such support for different kinds of authentication.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139599162550682902006-02-10T11:19:00.000-08:002006-02-10T11:19:00.000-08:00alejando.. what do you mean by making it available...alejando.. what do you mean by making it available faster. setting the passwords hashed doesnt really take any time?<BR/><BR/>rickard, how would you implement the LDAP solution to a, say, webmail application where the users need to access the webapp from random locations? If you can implement better solution than hashed passwords (salted and all) please tell me.<BR/><BR/>What comes to retrieving lost passwords, you just need to use tsl/ssl when you ask the verifying question, and after it give a forced password change form. since the password isn't know to the server, you either need to generate a new or trust that credentials were correct with the security question and have a valid login. and what point would it be to generate a quite hard password for the user for him to just forget it or change it immediatly. so let him do it after giving correct answer to the security question<BR/><BR/>NEVER ... NEVER EVER!.. send the password over unsecured connection.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139554292966562822006-02-09T22:51:00.000-08:002006-02-09T22:51:00.000-08:00alejandro, I sincerely hope that your comment was ...alejandro, I sincerely hope that your comment was not directed to me, because it saddens me to see that apparently you didn't read a single word of what I wrote.<BR/><BR/>Do Not Use Your Own User Database. Period.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139478204040056912006-02-09T01:43:00.000-08:002006-02-09T01:43:00.000-08:00TouchéI'm the one who had make User & Role pojos i...Touché<BR/>I'm the one who had make User & Role pojos in TRAILS.<BR/>I stored plain text password just to make it abalilable faster. I was planning to use MD5 after everthing else works. After all it is still under development :)<BR/>I promise you TRAILS will use MD5 to store passwords.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139384567658194472006-02-07T23:42:00.000-08:002006-02-07T23:42:00.000-08:00And I guess it's the kind of ignorance that Anonym...And I guess it's the kind of ignorance that Anonymous displays that is the reason for why so few store user information in an LDAP directory. Apart from being a blatant half-truth (a filesystem is a database too, but it's not really a database, is it?), it fails to recognize how LDAP directories are used in real life. <BR/><BR/>All of our customers who are not using a hosted solution have their own LDAP directory (either eDirectory or Active Directory) where they store their user information (and the hosted customers use directories since we provide it behind the scenes). They store it there in part because that's what UNIX and Windows networks integrate with, and in part because by doing so you don't get the double administration that having user information spread out in umpteen application databases would imply. <BR/><BR/>Another big benefit you get by using an LDAP directory is that they are actually quite well structured for what they are used. Not only can directories store user data, they can also store hierarchical organizational information, what groups users are members of, and groups can even be created dynamically based on user attributes. Things like that, stuff that matters. <BR/><BR/>That passwords are not stored as-is is so ridiculously rudimentary that it shouldn't even be a topic. <BR/><BR/>So by reinventing the wheel over and over again by using custom user databases you are on the one hand declaring your own ignorance, and on the other you are saying "fuck you" to your customer who will, once they get that second application, deal with the headache of keeping two user databases updated.<BR/><BR/>I see this problem with user databases ALLLLL the time, and the desperation of the customers and production people who have to deal with it is quite depressing.<BR/><BR/>If it wasn't so sad this whole tragedy would be funny.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139351330576630012006-02-07T14:28:00.000-08:002006-02-07T14:28:00.000-08:00Your're forgetting that a LDAP directory is nothin...Your're forgetting that a LDAP directory is nothing than just another kind of database...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139328221893132282006-02-07T08:03:00.000-08:002006-02-07T08:03:00.000-08:00I'm always amazed that people want to store user i...I'm always amazed that people want to store user information at all in a database. When you get to the point where you have two apps in an organization (which typically happens reasonably soon) then that user database is a f-g nightmare. Better to use an LDAP directory from the start. Or even better, develop your app as a portlet and avoid the user authentication completely.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139319636466968502006-02-07T05:40:00.000-08:002006-02-07T05:40:00.000-08:00as you cannot send them their old password (becaus...as you cannot send them their old password (because it's "encrypted"), you have to send a new one.<BR/>i let them enter the email they registered with, and then send a mail with a confirmation link, to make sure they really want their pw to be changed (and not someone else..). if there is an extra login name, don't send it in the mail with the new (random) password.. <BR/><BR/>i hate this "hint" approach: either it's too easy to guess for anyone who knows you , or it's to hard to remember for yourself. .)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139315294778196882006-02-07T04:28:00.000-08:002006-02-07T04:28:00.000-08:00> what is your strategy for providing> links "Lost...> what is your strategy for providing<BR/>> links "Lost your username / <BR/>> password" ?<BR/>I ask for hint and email new generated password if this don't break security. Otherwise I allow set new password.<BR/><BR/>What about https? How often do you have to logon/fill forms on unsecured http page?<BR/>I really don't like my data flow through my provider's proxies etc. But it seems many of site admins don't care about that.ciukeshttps://www.blogger.com/profile/05571319589211315191noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139261560343223172006-02-06T13:32:00.000-08:002006-02-06T13:32:00.000-08:00hi howard/all, what is your strategy for providin...hi howard/all,<BR/><BR/> what is your strategy for providing links "Lost your username / password" ? Do you usually ask for a hint and then send the users their passwords(which you can't since you don't store them) OR do you ask users to register a new password ?<BR/><BR/>BR,<BR/>~AAnjanhttps://www.blogger.com/profile/01902768305914200908noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139257188634314702006-02-06T12:19:00.000-08:002006-02-06T12:19:00.000-08:00When I suggested this very thing two companies ago...When I suggested this very thing two companies ago, the engineers expressed that it would only cause trouble and make their work more cumbersome as they usually forgot what the test accounts were.<BR/><BR/>The SHA-1 hashing was accepted nonetheless but not without the occasional groans about having to remember to call that stupid hashing method. Eventually everybody got used to it eventually and started groaning about some other difficult task.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139243017343518182006-02-06T08:23:00.000-08:002006-02-06T08:23:00.000-08:00No kidding, Howard. I am constantly amazed at how ...No kidding, Howard. I am constantly amazed at how often I sign up for something and I am sent my <I>username</I> and <I>password</I> as <I>plaintext</I> in an email! <B>TextDrive</B>--a company you'd think would know better--did this when I signed up recently. Inexcusable!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139241045275014292006-02-06T07:50:00.000-08:002006-02-06T07:50:00.000-08:00If it's an intranet application, the best way is t...If it's an intranet application, the best way is to even not have a storage for passwords; Just use the native, in-office identification method via some JAAS or whatever you are comfortable with.<BR/><BR/>Let the OS do the identification, if the users are already registered in its directory service, be it Active Directory or JES Directory.Avahhttps://www.blogger.com/profile/07163796019933955613noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-1139240899393538002006-02-06T07:48:00.000-08:002006-02-06T07:48:00.000-08:00I agree...except I use SHA-1, since MD5 is not so ...I agree...except I use SHA-1, since MD5 is not so secure anymore.Anonymousnoreply@blogger.com