Using the challenge/response Secure Login
Moderator: General Moderators
Aha, yes that's what I read in a couple of places. Thanks for mentioning it. It's not since long that md5 can be brute-forced, isn't it?
The more I'm learning about (php) security the more it amazes me how insecure most apps are. Most scripts you find online don't even use something like md5 to hash passwords. I've even seen a lot were input data isn't filtered and escaped at all, and it's assumed magic quotes is on, for example.
The more I'm learning about (php) security the more it amazes me how insecure most apps are. Most scripts you find online don't even use something like md5 to hash passwords. I've even seen a lot were input data isn't filtered and escaped at all, and it's assumed magic quotes is on, for example.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Welcome to reality. I spent a lot of free time (outside work) working in PHP games. My expertise is wasted, I know
But hey, tis a hobby.
Apart from a few games I've some across - two of which are coded by posters on this forum (Roja and panamajack), many others are severely lacking in security measures. I'm sure most other PHP areas are similar (where part timers are involved at least). But even stronghold applications have issues. phpBB just keeps popping up on security mailing lists as predictable as Christmas...
Last week I talked a guy into pulling a PHP game (closed source) from going live because after I was requested to check out the source I started coming up with lists of problems. Biggest problem is people just not filtering and escaping user input. Or just not taking a consistent approach to it (which leads to ad-hoc unpredicatable and tough to monitor measures).
In this game's case they are filtering (well sortof), but the devs were mixing up Filtering with Validation (not the same thing). It led to a few oddities where unfiltered data with an XSS attack was simply validated (as a string - with no other rule). Messy kind of error... There was also no escaping, so when the filtering failed... <shudder>
I'll quit the ramble now... But half the battle, if not 2/3s is simply educating yourself on the issues. You've made a good start - keep it up and you'll be more security conscious than the majority
Apart from a few games I've some across - two of which are coded by posters on this forum (Roja and panamajack), many others are severely lacking in security measures. I'm sure most other PHP areas are similar (where part timers are involved at least). But even stronghold applications have issues. phpBB just keeps popping up on security mailing lists as predictable as Christmas...
Last week I talked a guy into pulling a PHP game (closed source) from going live because after I was requested to check out the source I started coming up with lists of problems. Biggest problem is people just not filtering and escaping user input. Or just not taking a consistent approach to it (which leads to ad-hoc unpredicatable and tough to monitor measures).
In this game's case they are filtering (well sortof), but the devs were mixing up Filtering with Validation (not the same thing). It led to a few oddities where unfiltered data with an XSS attack was simply validated (as a string - with no other rule). Messy kind of error... There was also no escaping, so when the filtering failed... <shudder>
I'll quit the ramble now... But half the battle, if not 2/3s is simply educating yourself on the issues. You've made a good start - keep it up and you'll be more security conscious than the majority
Glad to hear you liked the book (and the articles). :-)matthijs wrote:Those articles by Shiflett are indeed very good. I have read them, as well as his book. Will have to reread it a couple of times, that's obvious :)
His book and articles, as well as a book like the php architect's guide to PHP security, make the potential problems very clear. My main problem is translating all those potential security problems to solutions for those problems in applications.
Every problem I describe in the book is followed by a solution. If any of the solutions are the least bit unclear, just let me know, and I'd be happy to explain them in more detail. That would also help me, because I'd like to make the book better and better over the years, so that it's a good source of information for the community.
Hi Chris,
Yes indeed, for all problems described there are also given one (or more) solutions.
I hope I can explain this well. What I mean is: reading your book and other articles about security, the viewpoint is - most of the times - the problem. Those are explained very well. But after heaving read about 20, 30,40 possible ways do some bad stuff, it's difficult to turn it around. You want to build an app, and what problems might arise? What things to consider?
So I didn't want to say that things weren't explained well enough. It's more the approach taken, the viewpoint.
I will give you a more thorough review of the book, and help you in any way to make your book even better (although that may be difficult). But I'll do that on a more appropriate place (your site or pm), to keep the moderators here happy.
Your dedication is apreciated, thanks.
Matthijs
Yes indeed, for all problems described there are also given one (or more) solutions.
I hope I can explain this well. What I mean is: reading your book and other articles about security, the viewpoint is - most of the times - the problem. Those are explained very well. But after heaving read about 20, 30,40 possible ways do some bad stuff, it's difficult to turn it around. You want to build an app, and what problems might arise? What things to consider?
So I didn't want to say that things weren't explained well enough. It's more the approach taken, the viewpoint.
I will give you a more thorough review of the book, and help you in any way to make your book even better (although that may be difficult). But I'll do that on a more appropriate place (your site or pm), to keep the moderators here happy.
Your dedication is apreciated, thanks.
Matthijs
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Feel free to discuss what you wish on that scene here. It's your thread, take it where you likematthijs wrote:I will give you a more thorough review of the book, and help you in any way to make your book even better (although that may be difficult). But I'll do that on a more appropriate place (your site or pm), to keep the moderators here happy.
-
ralfhauser
- Forum Newbie
- Posts: 1
- Joined: Sun Jan 01, 2006 8:00 am
Maugrim_The_Reaper wrote:That's pretty much it...
Using a challenge-response looks like a great idea to me.
Calculating the response with javaScript, however appears quite dangerous to me when thinking of today's phishing and other pests.
Shouldn't a response be calculated in a more trusted place such as for example pwsafe?
--> see my corresponding RFE https://sourceforge.net/tracker/index.p ... tid=429582
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
The javascript is sourced on the host server (whether genuine or not) so yes, a phish or other could remove that layer, induce a user to enter a clear password, and submit it to the evil people on the other side of the connection. Or worse.
But that's the risk of phishing with a javascript enabled browser involved... Not of using a C/R method for securing a password tranmission. The method itself does not pose a risk - it reduces a very real risk. Its just incapable of reducing that risk to a nice round 0.
Whether the C/R I describe is or is not ideal is not even the point. Its not intended to be ideal - its intended to be a stopgap measure in the absence of anything stronger. I would love the world to have access to free certified SSL or TLS. I would love there to be a super, standardised method for implemented C/R without javascript involved. Unfortunately when coding for a generic audience on shared hosts where the common denominator is important its not realistic. You meet lots of "ifs", "whens" and "optionally" terms down your route...
Is C/R dangerous? No
Is Phishing dangerous? Yes
Now addressing the actual vulnerability (the trusted javascript); any other method of both calculating and submitting via HTTP the correct response is entirely valid and possibly even superior. However its likely to require a third party requirement - and users are notoriously unlikely to go along with that. Then again, if one piece of javascript is insecure, how about all the others? Maybe we should ban javascript?
But that's the risk of phishing with a javascript enabled browser involved... Not of using a C/R method for securing a password tranmission. The method itself does not pose a risk - it reduces a very real risk. Its just incapable of reducing that risk to a nice round 0.
Whether the C/R I describe is or is not ideal is not even the point. Its not intended to be ideal - its intended to be a stopgap measure in the absence of anything stronger. I would love the world to have access to free certified SSL or TLS. I would love there to be a super, standardised method for implemented C/R without javascript involved. Unfortunately when coding for a generic audience on shared hosts where the common denominator is important its not realistic. You meet lots of "ifs", "whens" and "optionally" terms down your route...
Is C/R dangerous? No
Is Phishing dangerous? Yes
Now addressing the actual vulnerability (the trusted javascript); any other method of both calculating and submitting via HTTP the correct response is entirely valid and possibly even superior. However its likely to require a third party requirement - and users are notoriously unlikely to go along with that. Then again, if one piece of javascript is insecure, how about all the others? Maybe we should ban javascript?
The concept that ralfhauser is putting forward is that of a browser with a trustable C/R mechanism. Several problems with that idea:Maugrim_The_Reaper wrote:The javascript is sourced on the host server (whether genuine or not) so yes, a phish or other could remove that layer, induce a user to enter a clear password, and submit it to the evil people on the other side of the connection. Or worse.
1. Most users don't have it, and won't install it, even if you ask.
2. It doesn't buy you much additional security over a correctly implemented js C/R.
If your js C/R accepts a (reasonably strong/unique) salt, and sends only the salted, hashed password, then there is little additional benefit to a system like pwsafe.
For there to be a risk to protect against, you have to have a scenario where the phisher took control of the browser or PC of the user. The only difference then between pwsafe and js is how difficult it is for the attacker to subvert/replace that layer.
A salted, hashed password gives the attacker nothing. Even if they know the hash method, AND the salt (they created it, right?) they still don't get the original password.
If they are subverting the code to get the cleartext password, they can do the same against pwsafe.
The truth is, as you say Maugrim, that C/R is simply a layer of defense. Its not a perfect defense, and its not meant to be. Ideally, you should use C/R on top of SSL, with client certs, and more.
But realistically, for most sites, even C/R is a bit of overkill. We're not talking about protecting the pentagon's codes - we're talking about Bob's Website, which shouldn't be sloppy, but doesn't need to be Fort Knox online either.
Security is a process that reduces risk. C/R (even via javascript) is a solid improvement over the null state. Could pwsafe take it further? Possibly, but SSL would be a better investment of time and effort.