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

[Steve Winter]

Hi Bob,

I think these days it's just a combination of your imagination and a  
reasonably long memory...! In the 'old days' of https it was  
definitely slower, due mostly to the speed of the client computer and  
the capabilities of the browser as they did the de-encryption at the  
local end of things...

With modern PCs and browsers this effect is significantly reduced, to  
the point that it's no-longer any sort of reason not to do https (IMO)

Cheers
Steve


On 13 Feb 2009, at 01:31, Bob Patin wrote:

> 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
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list


Steve Winter
steve at bluecrocodile.co.nz
m: +44 77 7852 4776
3 Calshot Court, Channel Way
Ocean Village, Southampton SO14 3GR

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20090213/b800ff75/attachment.html