Password fields fine tuning

[Louis Amon]

I'm trying to improve user exprerience on my website and I noticed a rather annoying behavior on password fields :

If I type a password longer than 8 characters and somehow my form fails (some other field didn't validate), my password gets replaced by "********" in request.vars.password.

For example :

I try to login and misstype my username --> login form fails.

I correct the mistake in the username and press the submit button again --> login still fails, because the password got replaced by '*********' under the hood.

Another example:

I try to register and type my password but mistyped my password verification (password_two) --> register form fails.

I focus the password_two field and retype my password --> register still fails because the original password field got replaced...

This behavior is extremely frustrating for users as they can't print request.vars.password like a developper would. All they see is obfuscated passwords.

I cannot have this on my commercial website.

Is there any way to fix this ?

[Niphlod]

so you really want the webpage to return the actual password instead of asterisks ? it's a big security risk, no matter what user experience says.....

[Louis Amon]

I don’t see much of a security threat here.

What’s the worst-case scenario ?

If you take a look at airbnb.com, their registration form keeps your typed password even if you fail validation on other fields.

If a website that big can do it then surely my small website will pull though, don’t you think ?

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/T1vfDXDgsmE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Willoughby]

A simple google search will yield people complaining about their host accounts getting hacked on airbnb.
Just because someone or something large 'does it that way' doesn't mean it's a best practice!

[Louis Amon]

We’re all developers here so I couldn’t agree more.

Still, I’m running a commercial website so I’m a slave to what my users want.

As far as my customers are concerned, security comes second after ease of use…

Anyway, you have to admit that the examples I gave in the first post are misleading in terms of user experience, right ?

Isn’t there a way to improve it without compromising security too much ?

I can see one : erasing input fields after each validation failure (blank fields are less misleading). Do you see other ?

[Willoughby]

I can see one : erasing input fields after each validation failure (blank fields are less misleading). Do you see other ?

That's the one I've always understood to be the most secure - blank all the fields and don't indicate which field failed.

[Anthony]

I think common practice is to leave password fields blank after a login failure so the password must be re-entered.

In any case, I cannot replicate either behavior you describe using the standard web2p Auth forms. When I have a failed login, the entire login form is reloaded emtpy. When I enter the second password incorrectly on a register form, the form reloads, and I only have to correct the second password, not re-enter the first.

Can you show the code you are using for your forms?

Anthony

To unsubscribe from this group and all its topics, send an email to web2py+unsubscribe@googlegroups.com.

[Louis Amon]

@Anthony: Indeed, I forgot to add that I’m using auth forms through ajax via LOAD. The problem may be due to ajax's JSON conversion of request.vars.

[Anthony]

I still cannot replicate the behavior you observe. Can you show your code or attach a minimal app that demonstrates the behavior?

Anthony

[Louis Amon]

After much research I found the trigger to replicate the issue :

db.auth_user.password.widget = lambda k,v: SQLFORM.widgets.password.widget(k, v, _id="login_password", _class="input-basic input-200")

If you type a password longer than 8 characters and the validation fails, your password will be replaced with '********' in request.vars.password.

[Anthony]

I still don't see the behavior for login, but for registration, you can try:

db.auth_user.password.widget = lambda k,v: SQLFORM.widgets.password.widget(k,

    None, _id="login_password", _class="input-basic input-200")

Anthony

[Louis Amon]

That's a very elegant solution.

Thank you Anthony.

On Friday, July 25, 2014 8:01:53 PM UTC+2, Anthony wrote:

I still don't see the behavior for login, but for registration, you can try:

db.auth_user.password.widget = lambda k,v: SQLFORM.widgets.password.widget(k,

    None, _id="login_password", _class="input-basic input-200")

Anthony