I think this is a simple one, I want to display the authentication key during a password reset.
First, is there any problem with doing so? Is there some kind of hole I'm opening up? I control when a user is created and sent signup_instructions. I only have about 500 users. My system is one where in many cases, it is only used a few times a year, and by only one or two employees at smallish companies , average 10 employees. Some of the companies we service , rather than create multiple accounts for employees, share one or more accounts, i.e. I create it for a specific person at the company, then they share the password with their assistant(s). I use email addresses for authentication key.
Can you guess what's coming next? This really happened! User goes on vacation, young assistant needs to log in, forgot the password, but is savvy enough to click forgot password and reset it, she reads bosses emails while boss is gone. Boss returns from vacation, needs to log in, can't, but isn't savvy enough to click forgot password and didn't bother to read her emails that came in while she was gone. So she calls in a panic and pissed off, 'what's wrong, I can't log in!!!'. Many of my users are like that, older, not real computer literate.
So I need to take extra steps to idiot proof resetting passwords, which I'm thinking should include PROMINENT display of the email address they are about to reset, plus wording to remind anyone who's 'sharing' an account to inform their co-workers if they reset.
I tried this in my devise/passwords/edit
<%= resource.email %>
The above code yields nothing!
You should never expose authentication data. That's why you never send them with GET but instead with POST. Do some research: how does gmail reset passwords? Another thing to remember, once you have done all that's reasonable, a user is responsible for safeguarding his personal information. If the secretary knows everything about the boss, then that's too bad -- unless they want you to use biometric to reset passwords.
Related
I cant find any help around on this topic because I am being told how to implement it rather than how it actually works.
All I know is two-factor authentication is authenticating users through an email and a phone number.
Here are my set of questions :
Does it authenticate users by verifying their email and phone number at the time of registration?
Does it authenticate users by verifying their email and phone number on every login?
Why is it that every user can set two-factor authentication enabled or disabled for their account? Isn't this an admin thing which should not be decided by the user?
I'll see if I can help clarify for you.
It works as an extra level of security. Traditionally you would have a username/email and password to get into a site. If the password is compromised then so is the account. Adding a phone number to your account will mean that only someone with access to that phone can get past the extra level of security and access your data.
When the user logs in with another 'step' is added before they get through. A token (usually a number with a short expiry - i.e. seconds) is tied to the user logging in and sent to their phone. They fill in the form and submit. The device the user is logging in with (laptop/phone/desktop browser) can then be tied to their account (see point 2 below).
This can be the case but if you take Google as an example you can select to 'Trust' the device logging in for 30 days. This ties the device to a trusted list (perhaps stored in a database for instance) for a set amount of time before asking at the point of login again.
Common practice is that it is the user's choice as to whether they have this extra level of security. They may not have access to a phone...what happens then? They may like the convenience of just using a username/email and strong password....it doesn't mean to say you can't force it by design in your system though.
I'm writing an ASP.NET MVC application, which uses the Membership database to store user registrations. I use email addresses as usernames. When a user registers in my app, I send out an email-confirmation to the address they have used during registration. i.e. I send out an email with a link, which the user is supposed to click, to verify that the address belongs to him.
Until that link is clicked, the account remains 'Unconfirmed' (i.e. EmailConfirmed column equals False). Which means, the account is created, just not active.
How do I deal with a hacker who brute-force creates accounts? I see two big problems here:
Ever-increasing size of the Membership database. A single user, from
a single computer is not a threat, but what if he has 'zombie'
computers?
If User1 creates account with User2#example.com email and
User2 ignores the activation email, the account will essentially
remain locked (unconfirmed), but existing. If User2 decides later to
actually create an account, they can't use their email to register
(account already exists) and they can't Reset Password either -
because even if they reset the password, that does not necessarily
Activate the account.
As for 2) I see a couple of options:
Set expiration date on unconfirmed accounts - i.e. allow the username/email to be claimed again, if the email is not confirmed with 24hrs
Modify my Reset Password method to also activate the account, if it has not been activated. Is that a good idea? I mean, the person would receive an email for that, which is essentially a confirmation, if they click the reset password link in it.
Anything else?
What about 1)? How do I protect myself against bulk create of accounts? Aside from limiting 1 account per IP, per day, using code.
One simple way to deal with this kind of problem is crude but effective.
I usually add an additional field to the form that doesn't form part of what I need - but has a legitmate sounding name like 'Company' - and then I hide it from screen view using CSS. Real user's will never see this on screen, but a bot crawling through the HTML will find it.
Then, when the form is submitted, first I check to see if that form field has a value. If it has - I stop the page from executing any further or just return an HTTP Error as in 99.9% of times only a bot would have filled out that field - not a real user.
//anti-bot measure
if (!String.IsNullOrEmpty(Company.Text))
{
HttpContext.Current.Response.StatusCode = 400;
HttpContext.Current.Response.Status = "400 Bad Request";
HttpContext.Current.Response.End();
}
//carry on processing the form...
I've been using this technique on forms for several years and it's been extremely effective!
Here's the scenario:
A hacker hijacks the account of a user on my site. The hacker changes the password. My site sends out an email to the user's contact email address with a link containing a url with a hash value to reset the password. The hacker then changes the user's contact email address the following day. My site then sends out an email to the old and new email addresses.
Most answers here have said that the recovery hash should be valid for an hour. But what if the user is away from home and doesn't get the emails until a week later after the hash has expired? The user's password has been changed and can't get a new recovery email either. The user has now lost the account and has no way to recover it. Shouldn't the hash remain valid for a week or two, or until it is used?
And what happens if the hacker, knowing how this mechanism works on most sites, claims to forget the password and requests a new one. Should the site generate a new hash, replacing the old one, thereby rendering the real user's reset hash invalid? Or should the site not change the hash, and send out the same hash again? But now, both the real user and the hacker have a hash to reset the password?
I'm sooooo confused... Maybe there's no perfect solution to this problem...
Any other technique? I, personally, don't like "secret questions" because, more often than not, they provide a back door to hack into someone's account. When sites require them from me, I type gibberish as the answer.
BTW, I know there are similar questions like this, and I would have preferred to ask for clarification in a comment to an existing question rather than open a new question, but I don't have high enough reputation to add a comment to someone else's question.
I would set the hash until activated and a caphata is done because the hacker could use a bot to get on the website.
Edit: The Hacker will not know secret password for reset verification.
I am currently worrying about a password recovery method for users of a web application.
One idea would be to use an E-Mail with a recovery url, only asking the user for his/her user name, but if he/she forgot that too, ask for e-mail address.
Another idea would be to use "secret questions" and then send the password to the user.
Do you know any other, possibly better, options for password recovery? Are there any downsides, besides user frustration, to have a "wrong password limit"?
EDIT:
Yesterday I was told that in some of the older versions, which are still updated and used by some customers, neither E-Mail addresses nor user names have to be unique.
So I'm totally stuck now. The only thing coming to my mind is using a secret question which the user can select after first login. But instead of sending an E-Mail opening the "new password dialog" directly.
Do you have any more ideas?
My opinons:
Assuming you require a user's email address to be unique among all registered users have the password recovery page ask for the user's email address. You can make it "username or email address" but I don't think that little tweak will help enough users to justify your additional backend processing.
For added security do not confirm or deny that the username or email address was found in your database.
An email with a reset password link should work fine. Use a hash (the longer the better; definitely 20 characters or more) so a hacker can't easily guess reset links. For added security specify a time limit after which the reset link will no longer function.
Once the user clicks the link and chooses a new password, do not automatically log them into their account; make them login from scratch. This will make sure they know their new password and will reduce the chances of a bug in your password recovery code letting hackers directly login to accounts.
Remind users to check their spam folder, and provide a window of time in which they can reasonably assume they should receive the reset link (so they know how long to wait before complaining to you).
Security questions are usually a bad idea. First off, users struggle to remember what their answer was. It's like adding something to a user's password but giving the world a hint to what that extra part could be. AND the answers will tend to be case insensitive and only alphabetic or alphanumeric.
Make sure you include a way for the user to contact you if the password recovery system isn't working for them. Be cautious, though, as this could be an avenue for a Social Engineering hack.
Password limits can be frustrating for users. Think long and hard about implementing this, how many attempts you'll allow, and the consequences of exceeding that limit. Most people have variations of a single password. Now, that's not smart from a security standpoint, but it happens. A reasonably acting user could very well try hooper2012, Hooper2012, hooper20121, Hooper20121 in under a minute.
Maybe you could, say, after five failed attempts make the user wait 60 seconds between any future attempts. Double that to 120 seconds after an additional five failed attempts. Continue doubling the wait period every five failed attempts. If you let that continue until, say, 50 consecutive failed attempts the minimum amount of time it'll take to exhaust those 50 attempts will be 1 day 18 hours and 35 minutes. I'd definitely recommend having something in your code to notify you of any accounts with more than 12 consecutive failed attempts in a day.
After 50 consecutive failed attempts temporarily deactivate the account, and require the user to contact your technical support. Again, be wary of social engineering.
Reset the wait period to 0 once the user provides the correct login credentials.
I'm trying to use MyOpenID for my sign-in, but it doesn't seem to be sharing the email address.
If I use Google or others I do seem to get the email address, though. I thought that this was a standard field to return.
I even see some documentation here that seems to suggest they would share email:
https://rpxnow.com/docs/providers
(I'm using Ruby on Rails and Janrain for this project)
One interesting thing is that if I setup an identity page on MyOpenId, then the email IS shared with my application. I thought that there was supposed to be a way when logging in with MyOpenID to specify what data is shared during "SimpleRegistration"?
The problem was that I was testing with my own MyOpenId account and the very first time I logged in to my development server I had not paid enough attention.
When logging in the first time it said something along the lines of "blah site is asking you to share information with it. Click here to use an existing persona or to create a new one. I didn't select one and it defaulted to "don't ask again".
I was able to fix this by going in to MyOpenId and revoking permission for my site. Then the next time I logged in it asked me again and it worked.