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

[Leo R. Lundgren]

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.

-|