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