After some research I have implemented a solid "Forgot your password?" mechanism, and now I wanted to implement 2FA.
But now I'm thinking, what's the point of 2FA (password + email or SMS), if you can recover your account with the "Forgot your password?" mechanism, which only requires 1 factor (only email)?
Is it normal to have both or, as I'm now thinking, it's kind of pointless?
The idea behind the 2-factor authentication is, that people often use the one email addresse for all their accounts and additionally choose a weak password which they use for all their accounts.
So if someone else get access to that password on one system, this person will have access to all other accounts.
If the user has choosen a password for his email that is different to all others the situation is a little bit better. But there is still one problem that remains. If someone was able to guess that password the user would not recognize this until it is to late.
But if the mobile is lost or stolen the probability is height, that the user will request a blocking of the SIM card within a short period of time.
So you would send a confirmation code for actions of the account of the user that are uncommon or could result in loosing access to the account.
It is up to you to choose when you send a verification code. (Always on login, only on changes of account data e.g. Password, email, new mobile number or for actions that would create costs for the user)
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!
I intend to build a customized logic on Devise on Rails. Here is the logic: user can try to login, and if the does not exist, then it will create the account for the user. Just to skip the registration process.
Now sure how to hack into Devise. Please help!
Thank you in advance!
Edit: Sorry that I didn't make it clear enough: I have implement the on-create-validation on the user model to authenticate with another system. Logic is:
If success with another system's authenticator, then create a new user with the same password and login user.
Else login fail.
You know that if someone make typo he will create new account and will be mad that all of his/her stuff disappeared? When there is small amount of user then it isn't problem. But when your society will grow then it can make you some black-PR. You should rather check by AJAX call that there is user with that email/username/nick and if not then show the registration form, but on other hand this can be security issue if your users are signing in using non-public data like email or if username is different from nickname shown on your page.
Why would you want to skip the registration process? I don't see any benefits.
First, the user can enter the wrong username or password by accident.
Second, the user can enter the right username, but the wrong password. So he/she already is a registered user, but still get a new account.
Third, when a new user is automatically registered, how does the user actually now what his username or more importantly, his password will be?
Personally, why not just add "Remember Me" or "Forgot Password?" to your login form. If, for any reason, the user doesn't want to enter his login data or simply doesn't know his password required to login he can use these options.
Or, if you are working with permissions, why not just make a guest user if someone is not logged in?
What if they type in the wrong password or username on accident? Then you just automatically create them an account? IMO that would be a bad user experience. You either know your account or you don't. If you have an account and can't remember then you use the 'Forgot my ...'. If you don't have an account, then you go signup. You could implement oAuth and use accounts from a multitude of sites (i.e. Github, Twitter, Facebook, etc.) that would make it easier.
I'm developing an application that requires authentication with devise/rails and it was decided to allow users sign in without email confirmation. However, after a deep thinking this odd workflow came in mind:
What if someone registers with my email, starts using it and later
I decide to join the app with my stolen email? The guy did not
confirm, but should I keep his account, block it or remove it?
(side note: email must be unique)
As the designer of the application, you are in control. You can handle that situation how you would like.
I'm not sure how facebook deals with 'unconfirmed' account creations. I would imagine that they allow whoever registered to check their e-mail and click the confirmation link within a certain amount of time - after which that e-mail becomes available for use by other users. This makes sense to me, as this would prevent people from spamming the site and effectively 'e-mail blocking' legitimate users from registering. If you forever allow unconfirmed accounts to sit and 'use up' e-mails, you could run into the following situation:
A malicious user creates thousands of 'fake' account registration attempts with bogus e-mails. These e-mails sit and wait forever to be confirmed, but never will be because they don't exist (yet), acting as 'in-use' e-mails. Some time later, a legit user happens to create an e-mail account with GMail or whoever that happens to match one of the 'bogus' e-mails submitted by the malicious user earlier. This legit user is then unable to register his or her e-mail with your service because the malicious user has 'e-mail blocked' this address.
My personal opinion is to give the registrant a certain amount of time to confirm their address as legitimate, and if they never confirm within that time frame, just discard the account creation attempt.
I've a very similar problem and the solution I've arrived (not implemented yet) is to make the user choose the email he want if there is not other confirmed user with that e-mail.
Once registered the user will be uncorfimed/nonactive and will receive a confirmation e-mail, when it will follow the link it will confirm his e-mail and other can't use it anymore.
Most of these sites require you to verify your email by sending you an email link. Only afterwards can you create an account. This handily sidesteps the problem of someone trying to steal someone else's email: unless they can log into your email account, they simply cannot.
Do you have a 'resend confirmation email' action (you should) or 'password forgotten' action (you should)? With both I could reclaim the account with my email address as only I have access to my emails.
Also think about the case of the user who creates an account, forgets about it and creates another account with the same email address.
I am building an asp.net mvc web application.
Do I need to use captcha while user registration.
Because we make the user verify the email, by the standard way, like sending a link in the email and when the user clicks on the link, the email is verified.
Do you think bots can actually open an email and verify? And moreover the bots will need a new email address for every registration.
Yes, bots can create new email accounts and send and receive email from those accounts.
You don't need to use a CAPTCHA if your site is unlikely to be targetted by bots but if you are worried about an attack then a CAPTCHA is a good idea and fairly cheap to implement. You should bear in mind that it negatively affects the usability of your site and could make it difficult for some users to log in.
The "new email address" for every registration requirement isn't hard to beat (think mailinator.com) but I can't imagine a bot confirming your email, you just have to deal with sending out redundant emails and assess if that is an issue.
I think the jist of it can be summed up like this:
captchas help protect against
automated signups
email confirmation helps protect
against impersonation
Email confirmation is much easier than a good CAPTCHA for a bot to pass.