Re: [PHP] Re: for the security minded web developer - secure way to login?
Colin Guthrie wrote: I appreciate that https doesn't provide trust by default, but ultimately that's how Joe Bloggs public has been told to deal with it look for the padlock etc. etc. to be sure that your session is secure blah blah. Yeah. Which is probably because all of the intricacies are way beyond Joe Bloggs, so the issue was cut down to something about trust. Now with the HV certs the UI also has the company name in the URL and this *is* going towards a trust infrastructure. I googled, but couldn't find anything - what are HV certificates? /Per -- Per Jessen, Zürich (0.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: for the security minded web developer - secure way to login?
On Tue, Feb 17, 2009 at 3:11 AM, Per Jessen p...@computer.org wrote: Colin Guthrie wrote: I appreciate that https doesn't provide trust by default, but ultimately that's how Joe Bloggs public has been told to deal with it look for the padlock etc. etc. to be sure that your session is secure blah blah. Yeah. Which is probably because all of the intricacies are way beyond Joe Bloggs, so the issue was cut down to something about trust. Now with the HV certs the UI also has the company name in the URL and this *is* going towards a trust infrastructure. I googled, but couldn't find anything - what are HV certificates? /Per -- Per Jessen, Zürich (0.6°C) Perhaps EV (Extended Validation) certificates? These are the ones that get extra special treatment in the browser because the CA is supposed to go beyond merely verifying that the URL domain matches the certificate by making additionally validating that the certificate belongs to a real entity whose identity they have verified. They also cost the most. Andrew -- 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?
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] Re: for the security minded web developer - secure way to login?
well httpus seems like a good idea though. Thats the kind of response i was hoping for. :-) Maybe browsers would implement that idea in the future. I like that idea a lot actually. I mean when you login to your linux server the first time with openssh, you also have to accept the certificate. In the end you have to trust something somewhere anyway, even if it's just the programmers of the browser and other software... I mean who seriously looks through all the source code of the linux kernel even though it is open source? And even if someone does it (good on them), do they understand every single line? A back door could be just a few lines of hard to understand code, that you might skip. It could even be encrypted and assembly making it very hard to decipher. Who has that much time and brains? With windows you have to trust M$ even more because you cannot even look, and i seriously doubt anyone can disassemble the whole windows OS and read the code. They would not finish in this life time, not even through 50MB of source code i believe. That's a lot! A warning at the top of the page like as if there were blocked content would be sufficient until the user clicks to confirm the validity of of the cert. The warning could just stay until clicked or don't show me again or something like that. FF3 atm changes the whole page when a cert is not authenticated. httpus could have a small warning but leave the site in shape and let it work. This would also have to be implemented in web servers though, but why not? Seems like a brilliant idea to me. The warning could also only be displayed once. I mean you only get warned once that every form gets sent over an unsecured network anyway. I bet even you security contious have typed in something somewhere that you maybe shouldn't have :P. I certainly have... Anyway, good idea, suggest it to the Apache and FF developers and M$ might follow at some stage if they believe they can make $$ with it or they would loose some if they didn't :). Sorry, this is really loosing its (direct) context to PHP. But maybe you could even do a layer higher than the protocol and make a PHP module or something that encrypts requests in some way without the programmer having to be aware of it. Altho i cant think of any way right now since the browser does the request. Or maybe it could insert smartly a javascript and attach an event listener to all forms... How about a js library that even encrypts? One could use RSA or Diffie Hellman or similar for key exchange, all in js and php and store the session key in a cookie, just like the session id... Maybe js is a bit slow for those kind of calculations though. But maybe worth a thought. regards, Tim Tim-Hinnerk Heuer http://www.ihostnz.com Alanis Morissette - We'll love you just the way you are if you're perfect. 2009/2/17 Colin Guthrie gm...@colin.guthr.ie 'Twas brillig, and Michael A. Peters at 16/02/09 00:10 did gyre and gimble: 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. Yeah the cheap CA's are IMO actually a problem. I (personally) think we should have a new system for this scenario: http:// = totally insecure https:// = secure and to a reasonable degree of trust (e.g. no $12.00 certs!) httpus:// = secure but no aspect of trust. httpus:// would support SSL in exactly the same way as https but the UA would simply not display the URL any differently to a standard http connection. This would give responsible developers the ability to provide SSL services where they only really care about the pipe and not the trust aspect. The problem with the cheap certs is that people do not see much difference to the expensive ones and this leads to the possibility of being hijacked. The weakest link is always the end user not knowing any better. The High Validation certs used by big companies at least show up differently in FF now but if you were to replace it with a hijacked non HV cert, there is still a good chance most users would still use it. Sadly this isn't going to work without browser support tho' and that's very unlikely to happen at all. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker
Re: [PHP] Re: for the security minded web developer - secure way to login?
German Geek wrote: well httpus seems like a good idea though. Thats the kind of response i was hoping for. :-) Maybe browsers would implement that idea in the future. I like that idea a lot actually. I mean when you login to your linux server the first time with openssh, you also have to accept the certificate. In the end you have to trust something somewhere anyway, even if it's just the programmers of the browser and other software... If your server is remote, yes, the very first time you have to accept the public key. After that you can pass the key to other hosts you plan to log in. I mean who seriously looks through all the source code of the linux kernel even though it is open source? A lot of people do. That's how potential exploits are found. And even if someone does it (good on them), do they understand every single line? A back door could be just a few lines of hard to understand code, that you might skip. It could even be encrypted and assembly making it very hard to decipher. Who has that much time and brains? kernel engineer. The NSA. Etc. With windows you have to trust M$ even more because you cannot even look, and i seriously doubt anyone can disassemble the whole windows OS and read the code. They would not finish in this life time, not even through 50MB of source code i believe. That's a lot! At least parts of the windows source are made available to those who have a need to see it, have a lot of money, and are willing to sign an NDA. It's extremely hard to get access, but it can be done. A warning at the top of the page like as if there were blocked content would be sufficient until the user clicks to confirm the validity of of the cert. The warning could just stay until clicked or don't show me again or something like that. I agree - the way Opera does it is sufficient. FF3 atm changes the whole page when a cert is not authenticated. httpus could have a small warning but leave the site in shape and let it work. This would also have to be implemented in web servers though, but why not? Seems like a brilliant idea to me. The warning could also only be displayed once. The way opera does it, you click a button to accept it for one session. If you want to accept it permanently, you have to click the security tab on the warning and check a box. That's the way it should be done in FF3. It's not the job of FireFox to second guess the user. Inform them of the issue, but don't try to force them into rejecting it by making it over cumbersome to accept it. -- 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?
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
Re: [PHP] Re: for the security minded web developer - secure way to login?
Colin Guthrie wrote: Yeah the cheap CA's are IMO actually a problem. I (personally) think we should have a new system for this scenario: http:// = totally insecure https:// = secure and to a reasonable degree of trust (e.g. no $12.00 certs!) httpus:// = secure but no aspect of trust. Colin, I think you're mixing apples and oranges here - http(s) was never meant to provide any indication of trust. Besides, how do you suggest we distinguish between CAs with no trust and CAs with trust? /Per -- Per Jessen, Zürich (1.1°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: for the security minded web developer - secure way to login?
Colin Guthrie wrote: 'Twas brillig, and Per Jessen at 16/02/09 13:49 did gyre and gimble: Colin Guthrie wrote: Colin, I think you're mixing apples and oranges here - http(s) was never meant to provide any indication of trust. Besides, how do you suggest we distinguish between CAs with no trust and CAs with trust? Well you're probably right. I appreciate that https doesn't provide trust by default, but ultimately that's how Joe Bloggs public has been told to deal with it look for the padlock etc. etc. to be sure that your session is secure blah blah. Now with the HV certs the UI also has the company name in the URL and this *is* going towards a trust infrastructure. If you are e-commerce then trust is an issue and you should pay for one of the certs that turns your url bar a pretty color. If you just want a public/private key encryption, you don't need the pretty color and shouldn't be forced to use a CA. Trust the pretty color as authenticated. Perhaps where we should go is that even if the URL is https:// there is no UI change in the browser. Only if the cert is trusted by a CA should the browser UI change to indicate this in some way, with HV certs being explicitly indicated as such to increase the trust aspect. One idea I saw is to only show the lock when a trusted CA is used. I'm fine with that. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: for the security minded web developer - secure way to login?
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 the certificate doesn't match - whether or not I am self signed, so the man in the middle attack is really not the big deal FireFox makes it out to be. What they should do is a simple notification telling the user they can't verify the website is who it claims to be, and a link for more info if the user wants more info. But alas, that has nothing to do with php, so I apologize to the list. Anyway, back on topic - if you want to encrypt login, use SSL. You can self sign for free. If you don't want the FireFox 3 issue, there are a few free and plenty of cheap certificate authorties that FireFox recognizes. -- 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
