Password change form issue
Moderator: General Moderators
Password change form issue
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.
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.
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.neophyte wrote:viewtopic.php?t=38810
There are others in the tutorial section that cover secure login.
Re: Password change form issue
Yes. Don't validate the format of the password. Accept the encrypted version the user sends.AGISB wrote:Anyone got an idea for a solution or a script that I could use.
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.
You can check if the user types nothing, as then the field would be blank.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.
However, yes, you are correct, you could not test the length or complexity. And yes, SSL is the only way around that.
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?
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 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?
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.
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.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..
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
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
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.
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.
That's a good point.So it is way more secure to send the password in plain text then allowing the user to choose an insecure password
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
That's a good point as well.feyd wrote:Do some validation client-side. You already need the challenge-response code client-side anyways.
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?