[FX.php List] [Off] Using Clear Text Passwords/Registration Design

[Bob Patin]

My only thought about using HTPPS throughout a site is that it's not  
quite as fast--or is this my imagination?

Bob Patin
Longterm Solutions LLC
bob at longtermsolutions.com
615-333-6858
http://www.longtermsolutions.com
Twitter: bobpatin
iChat/AIM: bobpatin
FileMaker 9 Certified Developer
Member of FileMaker Business Alliance & TechNet
--------------------------
FileMaker hosting and consulting for all versions of FileMaker
PHP • Full email services • Free DNS hosting • Colocation • Consulting

On Feb 12, 2009, at 4:02 PM, Leo R. Lundgren wrote:

>
> 12 feb 2009 kl. 22.29 skrev Tim 'Webko' Booth:
>
>> On 13/02/2009, at 1:34 AM, Jonathan Schwartz wrote:
>>
>>> Hi Folks,
>>>
>>> Does anyone have advise or links to reference material on the  
>>> design of well-designed registration/log-in systems, particularly  
>>> involving the sending of passwords in cleartext?
>>>
>>> Here's the problem...some end users of a clients project complain  
>>> about receiving their passwords via email in cleartext.  Googling  
>>> the subject turns up an ongoing debate between security and  
>>> convenience.
>>
>> It should be about reasonable security for the system involved.
>>
>> A system for banking should be like Leo described.
>>
>> A user support forum doesn't really need all of that.
>
>
> Tim, I agree with you that the level of security (or in other words,  
> the amount of resources and effort put into it) should be reasonable  
> with regards to what is really needed.
>
> I would like to point out, however, that the few things I suggested  
> are really nothing special or hard to do/time consuming to  
> implement. It's all basic things that you'd do as part of your basic  
> code for the site. For example:
> 	- HTTPS: Just use it all over the site, force HTTP requests over to  
> HTTPS. A signed certificate doesn't cost much these days. If really  
> low-budgeted, use a self-signed certificate, but this will give you  
> encryption only.
> 	- Requiring somewhat sane passwords when the user sets them: Just  
> some logic code checking that you have at least two of each type of  
> characters, and a check for the length. If not satisfied, give the  
> user a notice and let them do it again. Also, make sure that the two  
> passwords entered match.
> 	- One-way encryption of users passwords, and authenticating against  
> the stored hashes: Instead of saving the password in clear text, use  
> an encryption function that can take the password as the subject to  
> encrypt, and the password as a salt. Then, to authenticate the  
> users, just do the same thing again with the login information they  
> submit and compare the result of it with the result that you saved  
> when they set up the password for their account. If the results  
> match, allow. So in short, one or two extra function calls is what  
> this is about.
> 	- An extra "reset your password page": Not a lot of extra work  
> since you already have the registration page done.
>
> My point is that there is no reason not to do the above. The extra  
> work is probably not even worth mentioning :) And it will probably  
> give your users a better confidence when they see that you take / 
> their/ security seriously.
>
> That part about their physical machines and e-mail accounts is a  
> problem though. Usually one is left to rely on their local security.  
> In order to protect against physical theft/breaches we'd need to  
> raise the level of security considerably.
>
> -|
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list