Password change form issue
Moderator: General Moderators
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
When using a challenge-response setup, yes I always have provide server-side corrections in case Javascript was disabled, which is actually quite simple. The Javascript either empties or writes "other" data to the hidden challenge field. If the challenge field is unaltered, Javascript is considered disabled and the password is considered plain-text thus going through the added validation sequence.
The problem is that there are extensions for firefox that disable certain javascript functions and let others thru.
So a check if javascript is running might just yield a desaster result as the check function might say it does and the validation function might not. Someone just need to write a small extension ofr this if it does not exist yet.
I think the only workable solution is SSL. I thought about a crypt function but javascript is openly readable so the result would be as open when the salt and crypt function is readable.
So a check if javascript is running might just yield a desaster result as the check function might say it does and the validation function might not. Someone just need to write a small extension ofr this if it does not exist yet.
I think the only workable solution is SSL. I thought about a crypt function but javascript is openly readable so the result would be as open when the salt and crypt function is readable.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
For an initial password setup you can probably obscure it so far, but in the end SSL is the only concrete solution. Javascript validation might help in some way, but it still may leave the server blind to the password's format and characteristics.
It's a weakness of using C/R - its an imperfect solution which targets the majority use-cases, not always the minority. It's playing a numbers games - you set a password once, and login maybe hundreds of times - which is most likely to be read across the network? Could be all, some, just a few...
Its not possible without relying on JS and leaving the server blind...
On another question earlier - you can force JS for a C/R system. The example I posted in the tutorial was primarily for a JS agnostic site. Just remove the plain text password checks and enable a warning message or redirect...
It's a weakness of using C/R - its an imperfect solution which targets the majority use-cases, not always the minority. It's playing a numbers games - you set a password once, and login maybe hundreds of times - which is most likely to be read across the network? Could be all, some, just a few...
Its not possible without relying on JS and leaving the server blind...
On another question earlier - you can force JS for a C/R system. The example I posted in the tutorial was primarily for a JS agnostic site. Just remove the plain text password checks and enable a warning message or redirect...
That's a good idea. If SSL is not available, you know the used passwords are difficult enough and js will be available that's a good option.Maugrim_The_Reaper wrote:On another question earlier - you can force JS for a C/R system. The example I posted in the tutorial was primarily for a JS agnostic site. Just remove the plain text password checks and enable a warning message or redirect...