Using the challenge/response Secure Login

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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 ;)
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Well thanks, you guys have helped tremendously, I'm really grateful for that! My background is html/css, so it'll take a while before I can return some favours here. (well maybe I can help with questions on the client side forum)
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

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.
Glad to hear you liked the book (and the articles). :-)

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.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

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
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

matthijs 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.
Feel free to discuss what you wish on that scene here. It's your thread, take it where you like ;)
ralfhauser
Forum Newbie
Posts: 1
Joined: Sun Jan 01, 2006 8:00 am

Post by ralfhauser »

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
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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? :)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

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.
The concept that ralfhauser is putting forward is that of a browser with a trustable C/R mechanism. Several problems with that idea:

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.
Post Reply