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

[Leo R. Lundgren]

Hi,

Use HTTPS all over the site, /including the start pages and pages  
that print out forms where sensitive data is to be entered/. The  
reason for not just using it on URLs that are POSTed to (i.e. making  
the forms post to HTTPS urls but having only HTTP for the form page)  
is that unless the page printing the form where the user enters their  
sensitive is secured, who knows where the form will send its data?  
The form page could've been hijacked and altered to make the form  
POST the sensitive information to a totally different site than your  
own.

Regarding passwords, or course there are scenarios where the system  
should create one. But usually, why not let the users enter a  
password themselves? That way there shouldn't be any need to send it  
to them by mail later on; they shouldn't need a reminder of what they  
entered as their password. You can enforce the use of mixed  
characters and numbers and special characters in the password, as  
well as the minimum length of it, at the input form for the password.  
And of course, make them have to type it in twice to get it right.

So, assuming the above, we shouldn't need to send the password to  
them upon registration/updating of their account. Next, if they ever  
loose/forget their account password, IMO the following applies;
	1) IMPORTANT: You shouldn't even be able to send them their  
password. If you are, that means their password is stored on your  
side in readable form, which is a big NO-NO! You should store it  
encrypted using a one-way encryption method.
	2) Even if you did have it in clear text, don't send it to them.  
Instead, send them a "reset your password" link, which takes them to  
a secure and encrypted page on your site, where they do the old  
"enter a new password", pretty much like they did when they first  
registered.


12 feb 2009 kl. 15.34 skrev Jonathan Schwartz:

> 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?

I don't have a link or anything, sorry :< And I surely haven't  
covered it all, but what I wrote in the beginning of this mail should  
cover the basics.

> 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.
>
> From personal experience, there seem to be a myriad of combinations  
> of how registration systems work. They might...or might  
> not....involve these components:
> 	- original data form
> 	- self-assigned or system-assigned password
> 	- change password on first use.
> 	- change password at defined intervals
> 	- email confirmation to complete registration
> 	- encrypted, encrypted with salt, etc
>
> And then there are the 'retrieve or reset password' routines.
>
> For reference, I am allowing the end user to specify the password,  
> sending the password in cleartext in the confirmation email and  
> also sending the password via email in cleartext in the 'retrieve  
> password' routine.  There is personal information involved.
>
> An additional question: Are we theoretically protecting from 1)  
> eavesdropping on emails as they are being sent, 2) theft of  
> recipient's emails/computer after being received, 3) theft/loss of  
> the client's database...or all of the above?

Since all of these are possible scenarios, yes, we should protect  
against all of it.

> I know that there isn't any single answer, and it depends on the  
> circumstances, but I was looking for a discussion or an article or  
> two that covers the subject.

-|