You are here: Re: Proposal for Lite Encryption for Login Form without SSL « PHP Programming Language « IT news, forums, messages
Re: Proposal for Lite Encryption for Login Form without SSL

Posted by Jerry Stuckle on 10/01/07 04:08

klenwell wrote:
> Another request for comments here.
>
> I'd like to accomplish something like the scheme outlined at this page
> here:
>
> http://tinyurl.com/3dtcdr
>
> In a nutshell, the form uses javascript to hash (md5) the password
> field using a random one-time salt (nonce) -- generated by php and
> pasted in the form -- that is then posted with the hashed password
> back to the server. This way the password is not sent to the server
> in plaintext.
>
> In the example cited above, however, the password is stored unhashed
> back at the server (i.e., in the database) and it's this problem
> that's been tying me in knots this evening.
>
> The most obvious way it seems to me to cut through the knot is to
> simply copy the server-side salt (sss) used to hash the pw in the
> database -- the salt is constant -- within the javascript portion of
> the form so that that client would:
>
> 1. ssspw = md5(sss + pw)
> 2. nssspw = md5(nonce + ssspw)
> 3. post (1) nssspw, (2) nonce, (3) username (in plaintext)
>
> Then on the server side, php would:
>
> 1. db_ssspw = fetch hashed password from db (which should == ssspw)
> using username
> 2. db_nssspw = md5(POST[nonce] + db_ssspw)
> 3. compare POST[nssspw] and db_nssspw
>
> While this does not expose the plaintext password or the hashed
> password in the database, it does make public the server-side salt
> used to generate the hash password by pasting it in plaintext in the
> javascript -- though it does not post it from the form back to the
> server.
>
> So questions:
>
> 1) Is exposing the server-side salt a terminal flaw in this plan?
> This would be the equivalent to a public key in public key encryption
> systems, no?
>
> 2) Does exposing the server-side salt render hashing the password in
> the database moot?
>
> 3) If this is flawed, is it still better than nothing, accepting as
> given that SSL has been ruled out? (The article above notes that
> Yahoo uses a system like this.)
>
> 4) Any better ideas for accomplishing the concept outlined here?
>
> Before I run this over to the cryptology newsgroup, I thought I'd give
> it an airing here.
>
> Thanks,
> Tom
>

Why do you need to use the same salt (or even the same encryption
method) for the database?

Also, sending the password over an unencrypted link (even if the
password itself isn't encrypted) doesn't really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация