Edit - migrated to ui Stack Exchange (please close this question)
Do you find it necessary/worthwhile to make a user repeat his password in a registration form, assuming that form includes an email address?
Pros: I imagine there are quite a few cases where users mistype their password in the registration form.
Cons: If you require a valid email anyway, he can always retrieve/reset his password via email - and for the users that do get the password right in the first try, this is yet-another-field-in-the-registration-form (which I prefer be as simple as possible)
I would say using the password reset functionality in place of double-entry is not horrible, but it would require a decent UI on the login page to ensure the "forgot your password" link is clear -- such as having it appear much bigger upon invalid password entry.
I'd personally go a different way: ask for the password after a 'verify your email address' message.
One thing to consider is you also need a valid email address -- so if they mis-enter their email, and also their password, their account is effectively locked. Many sites require clicking a link (and/or entering a code) upon account creation, in order to verify email address, before making the account active. If you're doing this, then there is an annoying UX thing to avoid: it's not always clear why my account doesn't work.
I've seen this personally where I enter a password during registration, but then it tells me "invalid password" when I try to login, rather than "your account is not yet activated". Minor, but an annoyance.
One way to get around this is to not ask for a password until they've clicked the link in the email, then you prompt to create a new password. You can use double-entry here, since it's the only thing on the form, and it's a pretty simple way to avoid an easy user mis-entry. Users are also quite used to this model, practically every password entry system works like this.
It also handles an additional use case, where the user themselves is not the one creating the account (not sure if this applies to you or not). Someone can create the account on the user's behalf, but then the user is still choosing their own password after clicking on the 'verify' link they get via email.
I do think that it is worthwhile - as an additional validation just to ensure that users havent mistyped the password (especially coz we cannot see the password being typed in most cases). I think it provides a sense of validation to the user as well that he is in fact sure of his password before he submits the form.
However, this is valid only in case of forms which do not allow you to copy / paste from one field to the other (I have used sites where their forms allow me to copy paste which inherently makes having the 2nd field completely useless)
Personally, however, i find it extremely irritating when a form makes me re-type my password. But i still do think that its a useful validation to have.
Related
I use few websites on which i would like to remember username and password.
Login mechanism is divided on two steps, in first user gives username and in next step password. Firefox remembers both of them but in next login try, username is not filled so I must fill it manually. It doesn't propose any values even if I start typing. Its not my website so I can't modify code to the working state. There is possibility that owner made it as intended but I don't care. I want to have autofill both fields, not only password field. It's my credentials, not owner of website. I have found some javascript code running as a bookmark
javascript:(function(){var fm=document.getElementsByTagName('form');for(i=0;i<fm.length;i++){fm[i].setAttribute('autocomplete','on');}})()
and it even worked for some time on one of these problematic websites (autofill proposed me a value after typed first letter) but now it doesn't work any longer.
The problematic website i want to have fully working autofill is
h**ps://www.orange.pl/twojekonto/zaloguj
Is there anything I can do to force it? Maybe other javascript inject by bookmark? I am using Firefox 91.0.2.
Is there any reason a site login needs a username/password? If an email address or cell number is supplied a text or email could be sent back at which point you would click on the link. Would this be enough to be considered authenticated by the site. Much like a password reset email/text, except you would be logedin instead.
Maybe this is not the correct forum to post this.
But, usually an username gives more sense of "ownership" / sense of belonging to an account.
Also for security reasons! I'd rather not give my personal email to everyone or in some places.
And if they already ask my email, I would imply my username is the information other users have access to, and not necessarily my email.
e.g. a Forum / Payments / etc...
There's an interesting problem I'm facing as an educator. I want to collect user names in a form, but when I do that, it automatically enables students to email themselves a copy of their response.
I believe there's a way to somehow poll who's responded. When you enable the "one response per user" option, it doesn't require a stored user name. I know the information is out there somewhere - I just don't know how to get to it.
Any help would be greatly appreciated!
EDIT: I neglected to be specific about the coding aspect - apologies. I'm generating the form programmatically, and wanted to know if the information is stored somewhere in the response when the one-response-per-person option is enabled. After more digging, it appears that the easiest way to deal with this is to use an extension to handle disabling the email option.
Thanks for all your help!
you cant get the user email unless you enable that option like you mentioned. yes google might internally know who you are if you were already logged-in but its not perfect because using chrome incognito mode for example would not detect the email.
one way I can think is to:
1) with apps script generate an array of all student emails and a random password. dump to a private spreadsheet and use as your database for the next script.
2) in your forms, ask first as a form question the custom username and password.
3) on another script you can generate form urls with prefilled usernames and passwords and email each student their own custom form url.
when the student opens the form to respond, the username and password would be prefilled already.
not perfect but a malicious user would need to hack the email and if they can hack their email then they could also impersonate the user logged-in.
I've been looking into storing user passwords in mysql and the ubiquitous reply is to store it using an encryption algorithm like MD5 or SHA1. But what if user x forgets her password and wants it to be sent to her? What then? I can't send her the md5 hash! How is this issue dealt with in the real world. Are there two databases? One to compare hashes and another for forgotten passwords? But what's the difference, both would be read-only by the sql user connecting to it at that time. So how do you do it? Thanks!!
It's pretty standard security practice to never send users their password. Instead, you offer a password reset utility that is tied to their ability to access their e-mail account, and/or ability to answer question about their profile (like a security question or what postal code they live in).
Functionality Outline:
User clicks "forgot password link"
User enters security challenge information (e-mail address, security question if desired)
System sends password reset e-mail with auto-generated link (with generated GUID in a querystring for instance)
System creates a password reset record containing the reset GUID, what user it is for, and when the key will time out.
User retrieves e-mail, clicks on link.
System matches GUID, deletes password reset record, sends user to password reset page.
The best solution is to send the user a link where they can enter a new password without having to enter the forgotten one.
This link should only work once and it should work only for a few hours.
Don't create a new password and send that by mail; users will feel tempted to use that password (ignoring the fact that is has been transmitted over an insecure channel).
You are correct that passwords should not be stored in plain text (they should be hashed) and therefore cannot be delivered to users who have forgotten their password.
Essentially, what you desire is a way to circumvent your normal authentication scheme and you should first be aware that such a mechanism is a back door to the application.
Very often an assumption is made that only the desired user can access emails sent to the email address registered with your application. It is on this assumption that the 'standard' password reset mechanism is based. Here's my take on that:
The forgotten password page is requested and the user is asked to enter their registered email address into a form which they then submit
The receiving code checks that the submitted email address is indeed registered and if it is:
delete any existing password reset tokens for this address from the appropriate storage
generate and store a new password reset token for this address
send an email to the user which informs them that
'someone' has requested a password reset
to click the link if they do indeed wish to reset
to ignore the email if they did not request a reset
respond to the form submission with a page which says something along the lines of "if the address submitted was registered then a reset email has been sent"
If the submitted address was not one registered with the application then do nothing but respond to the submission with a page which says something along the lines of "if the address submitted was registered then a reset email has been sent" - just the same as if the address was a valid one (this is to make it more difficult for someone to discover email addresses registered with the application)
The user then receives the forgotten password email and clicks the link within it. The link delivers the password reset token to the application.
Upon receipt of a password reset token, the code checks that the token exists in storage and that it has not yet expired. If these hold true, then you assume that it must be the registered user who submitted the token and you can allow them to set a new password (a simple form with password and password confirmation inputs and a submit button and which contains zero personal information - not even their name).
Once the password has been set, you can direct the user to the login page where they enter their credentials as normal.
This isn't a perfect scheme. It's a trade-off between security and convenience and make no mistake that it constitutes a back door to the application. For low value applications it is usually good enough.
Further reading:
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
Forgot Password: what is the best method of implementing a forgot password function?
Why is "Forgotten Password" bad?
Does it make any sense to include a captcha when registration already requires email confirmation? any added benefit or just a waste of effort?
Neither will prevent current bots from getting into your system if that is your reason for doing these. Usually email confirmation is done to validate that the user gave a correct email address if you have need to contact them (or spam them). I don't see the value in adding a captcha to that.