Re: [PHP] Back to Basics - Re: [PHP] Re: for the security minded web developer - secure way to login?
Brilliant. Someone who understood my intentions :) It's not only a good
exercise but also useful. Once done in PHP and various JS frameworks, we
could port it to other languages. Would suggest to support as many as we can
because they all have pros and cons. PHP first tho :) . Maybe just good old
javascript as a start although the frameworks make it a lot easier. Who on
earth has Javascript turned off these days anyway? I don't know anyone who
is that paranoid. Sorry if someone here is but i believe if you are scared
of javascript you might as well not turn on a computer. There are always
going to be security holes.
Good on ya mate. Looks ok as an approach. Didn't look into all the details
though. I would suggest to put it under the MIT License as LGPL and GPL are
kind of restrictive as to the usage. Donations welcome of course :P.
If you want to host/version control the source code somewhere, i can offer a
git repository on my hosting or setup svn for you if you prefer that. Please
no CVS, i hate it. Just let me know if you need it.
I can also help with some development at some stage. I also believe that the
approach that i suggested would actually work well, even with a salt in the
original password hash. Maybe that salt should be hashed with a timestamp or
the same random salt as well lol. Computing a hash is not that expensive but
sending the salt might make it quite insecure because then an attacker knows
it. But i guess the salt's intension is primarily that an attacker cannot
use a pre-computed hash database from dictionaries. So maybe just sending it
is fine.
I might draw some diagrams and put them online somewhere to make it a bit
easier to understand.
Regards,
Tim
Tim-Hinnerk Heuer
http://www.ihostnz.com
Katharine Hepburn - Life is hard. After all, it kills you.
2009/2/16 Rene Veerman rene7...@gmail.com
Just for this case, where authentication of the server isn't an issue, and
things like deployment cost are,
i'd like to propose that we on this list look again at securing login/pass
through onewayHash functions, in an otherwise non-ssl environment.
i hate to be a critic of the community here, but isn't this insistence on
SSL a bit eh... lazy?
here's a starter for a onewayHash-based login crypto:
and think that with a proper layout of authentication architecture, one can
really secure a login system without having the administrative overhead of
installing SSL everywhere, and the monetary cost for a SSL certificate for
each domain.
I wish to code such a solution into a really-free library (so probably LGPL
or GPL + MIT) over the next 2 to 5 months.
This library would be a complete SQL, PHP javascript package (jQuery
plugged in), targetted for the novice programmer.
I'm halfway (or more?) there, i think.
For my own CMS, i have taken the following approach, which i'd like to hear
your improvements on:
(For onewayHash() i have MD5 and SHA256 implementations in both JS and
PHP..)
SQL:
create table users (
user_id integer,
user_login_name varchar(250),
user_login_hash varchar(250),
user_password_hash varchar(250),
other fields
primary key (user_id)
);
create table preferences (
pref_system_hash varchar(250)
);
PHP (pseudo-code) , on system installation:
preferences.pref_system_hash = onewayHash ( randomStringLength(100) );
PHP , on user-create:
users[user_id].user_login_hash = onewayHash(user_login_name +
preferences.pref_system_hash);
users[user_id].user_password_hash = onewayHash (someGooodPasswordNot +
preferences.pref_system_hash);
PHP, on request of a login form:
challenge = makeNewChallenge ();
//checks since when [browser IP] has last received a new challenge, if
threshold : make a new challenge. else return old challenge.
//a challenge is a random string (+ special chars) pushed through the
onewayHash function.
html = '
form id=loginForm
input type=hidden id=sh name=sh
value=preferences.pref_system_hash
input type=hidden id=ch name=ch value=challenge
input id=plain_user name=plain_user/
input id=plain_pass name=plain_pass/
input type=hidden id=user_hash name=user_hash/
input type=hidden id=pass_hash name=pass_hash/
/form
';
sendHTMLtoBrowser (html);
Javascript: on page with login form:
jQuery('#loginForm').submit (function () {
var sh = jQuery('#sh')[0]; //same for ch, plain_user, plain_pass,
all the inputs in the html form.
user_hash = onewayHash ( onewayHash ( plain_user.value + sh.value )
+ challenge );
//same for pass_hash basically
plain_user.value = ''; //clear out the plain text fields so they
dont get transmitted (same for plain_pass ofcourse)
jQuery.ajax ( /* submit login form through POST, handle results */ )
}
PHP, on receiving the login form data:
// walk through all the records in
Re: [PHP] Back to Basics - Re: [PHP] Re: for the security minded web developer - secure way to login?
On Feb 16, 2009, at 6:11 AM, German Geek wrote: Brilliant. Someone who understood my intentions :) It's not only a good exercise but also useful. Once done in PHP and various JS frameworks, we could port it to other languages. Would suggest to support as many as we can because they all have pros and cons. PHP first tho :) . Maybe just good old javascript as a start although the frameworks make it a lot easier. Who on earth has Javascript turned off these days anyway? I don't know anyone who is that paranoid. Sorry if someone here is but i believe if you are scared of javascript you might as well not turn on a computer. There are always going to be security holes. There are people who aren't in control of the computer they use. Such as anyone in a big corporation... The IT department might have decided to turn off javascript support to help protect their companies internal assets. Or Alot of people who use mobile devices that don't have java support. All I'm saying is there is a chance that even people who would want to leave java on normally might be in situations where they can't have it on. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Back to Basics - Re: [PHP] Re: for the security minded web developer - secure way to login?
yes there are situations like that but then it could just submit the form (which would happen anyway) and check the plaintext password like normally if the other mechanism fails. If people have js turned on it would simply increase security a little. The crucial part is just the sending of the password. Since it will not be a SSL url security aware ppl will not use their high priority passwords anyway. It's just for sites like facebook where you dont have to do money transactions etc. Tim-Hinnerk Heuer http://www.ihostnz.com Fred Allen - California is a fine place to live - if you happen to be an orange. 2009/2/17 Jason Pruim ja...@jasonpruim.com On Feb 16, 2009, at 6:11 AM, German Geek wrote: Brilliant. Someone who understood my intentions :) It's not only a good exercise but also useful. Once done in PHP and various JS frameworks, we could port it to other languages. Would suggest to support as many as we can because they all have pros and cons. PHP first tho :) . Maybe just good old javascript as a start although the frameworks make it a lot easier. Who on earth has Javascript turned off these days anyway? I don't know anyone who is that paranoid. Sorry if someone here is but i believe if you are scared of javascript you might as well not turn on a computer. There are always going to be security holes. There are people who aren't in control of the computer they use. Such as anyone in a big corporation... The IT department might have decided to turn off javascript support to help protect their companies internal assets. Or Alot of people who use mobile devices that don't have java support. All I'm saying is there is a chance that even people who would want to leave java on normally might be in situations where they can't have it on. :)
Re: [PHP] Back to Basics - Re: [PHP] Re: for the security minded web developer - secure way to login?
Rene Veerman wrote: Just for this case, where authentication of the server isn't an issue, and things like deployment cost are, i'd like to propose that we on this list look again at securing login/pass through onewayHash functions, in an otherwise non-ssl environment. i hate to be a critic of the community here, but isn't this insistence on SSL a bit eh... lazy? No. It's the right way to do it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Back to Basics - Re: [PHP] Re: for the security minded web developer - secure way to login?
Just for this case, where authentication of the server isn't an issue,
and things like deployment cost are,
i'd like to propose that we on this list look again at securing
login/pass through onewayHash functions, in an otherwise non-ssl
environment.
i hate to be a critic of the community here, but isn't this insistence
on SSL a bit eh... lazy?
here's a starter for a onewayHash-based login crypto:
and think that with a proper layout of authentication architecture, one
can really secure a login system without having the administrative
overhead of installing SSL everywhere, and the monetary cost for a SSL
certificate for each domain.
I wish to code such a solution into a really-free library (so probably
LGPL or GPL + MIT) over the next 2 to 5 months.
This library would be a complete SQL, PHP javascript package (jQuery
plugged in), targetted for the novice programmer.
I'm halfway (or more?) there, i think.
For my own CMS, i have taken the following approach, which i'd like to
hear your improvements on:
(For onewayHash() i have MD5 and SHA256 implementations in both JS and
PHP..)
SQL:
create table users (
user_id integer,
user_login_name varchar(250),
user_login_hash varchar(250),
user_password_hash varchar(250),
other fields
primary key (user_id)
);
create table preferences (
pref_system_hash varchar(250)
);
PHP (pseudo-code) , on system installation:
preferences.pref_system_hash = onewayHash ( randomStringLength(100) );
PHP , on user-create:
users[user_id].user_login_hash = onewayHash(user_login_name +
preferences.pref_system_hash);
users[user_id].user_password_hash = onewayHash (someGooodPasswordNot
+ preferences.pref_system_hash);
PHP, on request of a login form:
challenge = makeNewChallenge ();
//checks since when [browser IP] has last received a new
challenge, if threshold : make a new challenge. else return old
challenge.
//a challenge is a random string (+ special chars) pushed through
the onewayHash function.
html = '
form id=loginForm
input type=hidden id=sh name=sh
value=preferences.pref_system_hash
input type=hidden id=ch name=ch value=challenge
input id=plain_user name=plain_user/
input id=plain_pass name=plain_pass/
input type=hidden id=user_hash name=user_hash/
input type=hidden id=pass_hash name=pass_hash/
/form
';
sendHTMLtoBrowser (html);
Javascript: on page with login form:
jQuery('#loginForm').submit (function () {
var sh = jQuery('#sh')[0]; //same for ch, plain_user,
plain_pass, all the inputs in the html form.
user_hash = onewayHash ( onewayHash ( plain_user.value +
sh.value ) + challenge );
//same for pass_hash basically
plain_user.value = ''; //clear out the plain text fields so
they dont get transmitted (same for plain_pass ofcourse)
jQuery.ajax ( /* submit login form through POST, handle results
*/ )
}
PHP, on receiving the login form data:
// walk through all the records in users table, for each, calculate:
user_hash = onewayHash ( users[user_id].user_login_hash +
challenge );
pass_hash = onewayHash ( users[user_id].user_password_hash +
challenge );
// if they match what was sent, then it's the user we're looking
for with the right password, so their $_SESSION['authenticated_user'] =
updated.
If you have a completely alternative way of securing a non-ssl login
form, i'd like to hear about it too.
Michael A. Peters wrote:
Colin Guthrie wrote:
'Twas brillig, and German Geek at 15/02/09 22:32 did gyre and gimble:
Please enlighten me why it is so expensive? Is it maybe just the
hassle of
setting it up?
The whole thing is about trust. Getting a certificate is nothing if
the system is not backed up by a trust system. If a CA was setup that
gave out certificates willy nilly to all and sundry, then this
element of trust is lost.
Cheap CA's do exist. They have crappy web sites and send you all kinds
of junk mail etc. if you use them - but they do exist.
I might end up just paying godaddy - I think they charge $12.00 /
year, but since I already register through them, they already have my
address etc.
But the problem I have with FF3 is that I shouldn't have to.
I don't need to prove to the user that I am really me, and I don't
want to use a cert that some other organization has control over and
can choose to revoke at any time. I just the flipping password
encrypted by SSL so that when Betty who uses the same password for
everything (it's amazing how many people do) logs onto my server while
she has coffee at Starbucks, her uname/password isn't sniffed giving
Cracker Jack access to Betty's PayPal account.
If Cracker Jack wants to do a man in the middle attack - as long as
Betty has already connected to me before, her browser will still
inform her that
