Password change form issue

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

AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Password change form issue

Post by AGISB »

I have a little trouble with my password change form. As I was introducing the challenge response to a project I of course have to secure those pages that require to retype the password like username change, password change or email change. Username and email are not the problem but the password one is.


As I need to get the new password in clear text to check if it is in the right format (e.g. required number or special char). So challenge response or using seeds is not an option as it is one way.

So the only option (besides SSL) would be to use a javascript encryption that can be decrypted by php. As I am a total newb in javascript I would have to use a opensource function for this.

Anyone got an idea for a solution or a script that I could use.
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

viewtopic.php?t=38810

There are others in the tutorial section that cover secure login.
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

neophyte wrote:viewtopic.php?t=38810

There are others in the tutorial section that cover secure login.
You might want to reread my post. It clearly states that I have no trouble with the challenge response but it does not apply at all to the problem.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Re: Password change form issue

Post by Roja »

AGISB wrote:Anyone got an idea for a solution or a script that I could use.
Yes. Don't validate the format of the password. Accept the encrypted version the user sends.

Anything else will mean the password is available at some point in cleartext - whether across the wire, or on your server. Either way, thats insecure.
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

That is unacceptable. I cannot even check if the user just types nothing or just a space as a password. This poses a way bigger security issue than the openly transmitted password. I guess SSL is the only way then.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

AGISB wrote:That is unacceptable. I cannot even check if the user just types nothing or just a space as a password. This poses a way bigger security issue than the openly transmitted password. I guess SSL is the only way then.
You can check if the user types nothing, as then the field would be blank.

However, yes, you are correct, you could not test the length or complexity. And yes, SSL is the only way around that.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Interesting problem. On one side you want to be able to check the plain text string to be able to make sure the password choosen by a user is long and complicated enough. On the other side, you don't want to send the password plain text over the net (that's the whole purpose of the challenge response).

I would be interested as well in what solutions are possible in this case. Is there another one besides the obvious SSL? From what I understand from Roja there is none?
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

matthijs wrote:Interesting problem. On one side you want to be able to check the plain text string to be able to make sure the password choosen by a user is long and complicated enough. On the other side, you don't want to send the password plain text over the net (that's the whole purpose of the challenge response).

I would be interested as well in what solutions are possible in this case. Is there another one besides the obvious SSL? From what I understand from Roja there is none?
Well, you could code a complexity check in js, but the user could disable it.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Yes, that's the first thing I thought about as well. But indeed, js can be disabled. Thinking about that, would it not be possible to design the challenge response code so that js must be enabled, and that the c-r code itself check the length and complexity of the used passwords? Off course relying on js is not a good thing. But I can imagine that if you build some application you could make the availability of js a requirement. But on the other side, as js is client side there's no control over it at all.... hmmm, difficult stuff.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post by josh »

Without javascript the only thing you can send is a plaintext anyways...

Also if the user wants to disable JavaScript in order to make their password easier to guess, well then just let them compromise their own account..
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

jshpro2 wrote:Without javascript the only thing you can send is a plaintext anyways...

Also if the user wants to disable JavaScript in order to make their password easier to guess, well then just let them compromise their own account..
Unacceptable. Member areas are mainly protected to keep the information secure and only on the side to protect the user. If I allow a user to choose like 1 space for a password or something like 'pass' or 'password' I can just place the info without protection as every script kiddy has the account cracked in like 15 seconds max.


Challenge Response is just an additional layer that does no harm when disabled. The amount of knowledge that is required to intercept the transmission is way higher and the chance for every Joe Cracker to get in is not so high.

So it is way more secure to send the password in plain text then allowing the user to choose an insecure password
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Do some validation client-side. You already need the challenge-response code client-side anyways.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

When the user logs in, are they logging in in SSL? If not, it would seem to defeat the purpose of encrypting before posting.

On a side note, Javascript does utilize an MD5 function. I think it supports regex also. Why can't you use a regex to check for at least one lower case, one upper case, one number and one special char onBlur from the password field. Then, onBlur from the challenge field have Javascript check the MD5 values of both to make sure they match.

To be on the safe side I would put this process inside a hidden div that only shows on a JavaScript onClick event. That way, if the user has disabled Javascript they would never see the form, hence, would not be able to bypass client side checking because they would never be offered a chance to change their information.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

So it is way more secure to send the password in plain text then allowing the user to choose an insecure password
That's a good point.

And what if you would let the system make the password? So someone signs up with a username and his or her email address, and recieves the password by email (o wait, that can be sniffed as well isn't it?). Then you are sure the password is long and difficult enough. Then when the user wants to login, use the challenge response. So the plaintext pw is only sent once by email to the user, and not every time the user logs in. Wouldn't that be a tiny bit better?

One other drwaback would be that people would prefer to choose their own easy to remember passwords. But as we all know those are easy-to-crack as well :)
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

feyd wrote:Do some validation client-side. You already need the challenge-response code client-side anyways.
That's a good point as well.
But as js can be disabled, even without the user knowing it, maybe it would be an idea to back up that client side check for a difficult enough pw with a server side check in case js has been disabled. So
1 - Js enabled. Ch-R is used + client side validation for difficulty pw. The encrypted/hashed pw is sent to server
2 - Js disabled. Server side notices Ch-R is not used (receives plain text pw), checks the pw for difficulty
What do you think?
Post Reply