Funny Fact, but don't know how it's happening. Just curious.
In the setting page of my Github account, showing "The password you provided is in a list of passwords commonly used on other websites. To increase your security, you must update your password...."
It seems to be normal but once I think deeper, I don't really get how Github knows my password is commonly used by other website!
I mean in the "other website's" perspective, Github supposingly does not know what set of password is used by its' client, then how Github know its' own client password is commonly used from other website?
As mentioned in this thread, since Q2 2020:
While the password you have at present may meet the listed requirements, the system also runs a check when you provide your password (during sign in, or sudo access).
The check compares a one-way hash of that password against our internal database of credentials known to be compromised by breaches of other websites or services.
The weak password message you received indicates that the password you have entered was used by someone (not necessarily yourself) on a website that was compromised, which means it’s on lists used by malicious actors in their automated takeover attempts.
So the comparison is about password hash, not the actual password.
The thread adds:
GitHub uses both open and private paid sources of breach data in order to protect customer accounts.
We don’t typically name our vendors and in some cases we are actually precluded from doing so by contract. The exception, of course, is where we share customer data with a vendor 5, and that isn’t the case here.
We have two different responses to any matching credentials:
If there is a direct match - ie, your exact email and your password are present in a breach - then we force a password reset.
You won’t be able to use your account again until you have reset your password.
A direct match presents a high risk to the security of your GitHub account, and by extension, any GitHub repositories or organisations you have access to.
If there is an indirect match - ie, your password has been in a breach, but not necessarily your exact email address - we then warn about a weak password, and give you a window of time in which to change it.
This is a lower risk scenario, but still a risk.
We’re aware that we do take a conservative approach here, and that is constantly under review.
We understand that some people would prefer to be a little more relaxed about security themselves, but again, account takeovers create a substantial workload for us, and at present, an opt-out function is not an option.
I would like to use Stitch to sign up users. Each user must have a unqiue email and a unique user-name.
This is important for applications like chats or forums, where users should not be forced to reveal their email when communicating.
I already implemented login with email and password as described here: https://docs.mongodb.com/stitch/authentication/userpass/#authenticate-a-user
The problem is:
How to securely save a user-name on signup? I could store a users desired name in a collection and merge it into his custom user data after initial login. In order to do that, I would need to grant the user write privileges to whichever collection holds pending names. This is unsafe, since he could now change the name after the fact or even change other peoples names while they are pending.
The user needs to choose his name at the time of signup. At this time the user is still logged in via anonymous credentials. Hence, I can not restrict users to changing only their own data since they are at this point sill anonymous. I see no way of linking a users data to his future account at the time of signup. Any idea to change that?
It would seem strange, if stitch lacked the functionalities to easily sign up users with a unique name/handle in addition to email address.
I haven't used your exact software but in general I would approach the problem as follows:
When someone starts using the application anonymously, create a user object. The user at this point does not have a reserved (i.e. globally unique) user name, or email address, etc. But the user still has an internal identifier.
Associate user-visible state with the user object. This could be done through server-side sessions or signed cookies. (Unlike unsigned cookies, cryptographically signed cookies permit server to store what would otherwise have to be stored in the server-side session in a cookie, and trust that the client hasn't tampered with the information by e.g. changing the user id).
When user registers, set the user name, email address, etc. on the existing user object. User id remains the same and allows the user to continue to have access to their anonymously-generated data.
Have a process for deleting anonymous users that don't register after some time.
As far as I can think, there are two reasonable ways to reset a user's forgotten password.
Have the user enter their email address and a new plaintext password is sent to their email address.
A link is sent to their email address which has a UID number in the URL. Clicking on this takes the user to a form on the website where they can choose there own new password.
Which method is preferable and why?
If method 1 is used, perhaps a third party could read the email and obtain the new password.
If method 2 is used, what is to stop someone methodically going through UID codes to try and access the form to change a user's password?
The best pattern would be :
User requests password reset. Best is to do it through username, and
don't indicate if the username exists or not (to avoid possible
users listing through a script)
You generate a record in a new database table with userid, datetime
of request (= current datetime), and a GUID you just generated
You send a mail to the user, pointing to password reset page with
the GUID (not the userid) as parameter
On this page, you should check that the GUID is existing, and
eventually you could put some expiration date (=the user has 1 day
to reset, for example)
Don't forget to mark the record as "used" (with an extra field in
the table) when the user reset his password, so that you can stop an
eventual second try...
It could possibly even more secure, but that is already quite good I think....
OWASP has a good checklist of https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
Here is a quick summary of steps:
Gather Identity Data or Security Questions
Verify Security Questions
Send a Token Over a Side-Channel
Allow user to change password
Verify if the sender is the real user by asking verification questions.
Do not send password on the personal email that is not on the planate employees list.
Do not add the word "password" to the title or body of the email.
Make sure to send separately the username and password.
For Office 365 user, direct them to the forgot my password area or send this link https://passwordreset.microsoftonline.com
Don't get intimidated by the user, escalate to IT manager if the need arises.
Many sites implement different methods and I am having a hard time deciding on which method would work best for my site.
My user profiles contain the following data:
username
password (in hash/digest form)
email
I'd like the password reset method to be secure, user-friendly, and efficient.
You should add two fields, reset_code and reset_expiry
This is the process for a secure password reset functionality.
User selects "Forgot password".
User prompted for email/username.
If valid, generates a GUID, and stores it in reset_code and also stores Now()+24 hours in reset_expiry in the database against that particular user.
Then it sends an email to the email address with a link to confirm the password reset. This email would contain a link to your website with the user's username AND reset_code embedded. (This stops a malicious user resetting a third parties password just by knowing their email)
Once the user clicks on the link in the email, they will be directed to your website.
Your website will validate that: the username and reset_code matches, and the current time hasn't exceeded the reset_expiry time.
If all is okay, we can complete the password reset. This can be done by either:
a) Onscreen a new randomly generated password
b) A new randomly generated password via email
c) The ability to enter a password of his/her own choosing
You should not store the passwords of your users, not even in encrypted form. You should only store the hash/digest necessary for authentication. Then, you can't "recover" the password (because you don't know it), you can just reset it, and/or give the user a temporary one-time password that allows him to set a new password.
Update: if you are doing the above, the standard procedure is to have a "require-password-reset" form. The user enters his id (typically his email) and a "token" (eg, a random string) is generated, stored in some table with some expiration date, and sent to his email along with a link to the "password-reset" form. In this form the token is checked, the user is allowed to enter a new password, and instructed to attempt a new login.
Update 2: A small privacy issue might arise: What should we do if the user id (email, user name, or whatever) entered in the request form does not exist in our database? To output a message "User does not exist. Check the id and retry." may be ok, but in some cases it would cause a privacy problem: anyone can check if other someone is registered in your database! If you want to avoid that, you must output the same message ("a mail has been sent with instructions...") even if the user wasnt found (and hence a mail was not actually sent).
Similar privacy issues advise to just output the message "login incorrect : bad user or password" when the user tries to login unsuccessfully - don't disclose if it was an incorrect user or password.
I agree with Leonbloy. Storing the password leads to trouble like the Gawker incident from a few weeks ago (1.5 million userid/pwd combinations were discovered and published).
You should, however, have a "reset password" function that e-mails the new password to the original e-mail address used to open the account.
There should be no provision for changing the e-mail address during the password reset. If the user doesn't have access to the old e-mail account anymore, too bad. Abandon the account and start over.
And use a good Captcha on the reset screen.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm creating a web app that requires registration/authentication, and I'm considering using an email address as the sole user id. Here are what I see as the pros and cons (updated with responses):
PROS
One less field to fill out during registration (it would just be email address, password, and verify password). I'm a big fan of minimalistic registration.
An email address is easier to remember. (thanks Mitch, Jeremy)
You don't have to worry about your favorite username being taken already - you're the only one who uses your email address. (thanks TStamper)
CONS
User has more to type every time they log in.
What if a user wants multiple accounts? They'll need another email address. (Do I even want a user to be able to create multiple accounts?)
Easy for a potential attacker to guess (if they know the target's email address, they know the login id). (thanks Vasil)
Users may be tempted to use the same password they use for their email account, which is bad security. (thanks Thomas)
If you change email addresses frequently, it may be difficult to remember which address you used to sign up for a site after a long hiatus. (thanks Software Monkey)
A hacker could spam the registration form and use "email already taken" responses to generate a list of valid emails. (thanks David)
Not everyone has an email address. (thanks Nicholas)
If I went with email as id, I would provide a mechanism to allow it to be changed in the event a user changes address. In this case users would not be posting content to a public site, so a separate username won't be necessary to protect the email addresses (but it is something to consider for other sites).
Another option is to implement OpenID (which is a whole other debate).
This seems to work for Google, but their services are tightly integrated. What have I missed in my analysis? Do you have any recommendations? Does anyone have experiences to share?
FINAL EDIT
Thank you all for your responses. I have decided to use email as an id, but then allow the creation of a username for login purposes after registration. This allows a little flexibility while keeping registration as short as possible. It also prevents problems when a user changes email addresses (they can just log in with their username and update it). I will also be implementing methods to prevent brute-forcing of email addresses out of the registration and login systems (mainly a cool-down period after repeated attempts).
Personally, I prefer just using my email address as a username. It's one less thing to remember, and I never have to worry about my preferred name being already taken.
Just my 2 cents!
I think you missed a PRO:
Users are likely to remember their email address; and as email addresses are unique, they never have to worry about their preferred username being taken already.
As a user of websites, I can tell you that I hate memorizing unnecessary usernames. I don't use a unique handle or anything so I can never remember which variation of my name I used that wasn't already taken. I'd much rather type my email address.
Also, I like OpenID.
CONS
When the same password is used for the e-mail account, compromising the one automatically means compromising the other.
CON: Not everyone has an e-mail address. Consider if your database is ever accessed by an internal application. If you are running a store, people will call up and place an order by phone and refuse to provide an e-mail address. So while having an e-mail address as the default user ID is cool, be sure to allow alternates to get into the system. (Of course, this depends on the context.)
Learned this one the hard way.
I tend to not prefer pro/con lists, and instead try to think of benefits and challenges.
Challenge:
Some users will be tempted to use their email address from their ISP. Linking to an email alone, may be difficult for the users who forget to update their email in all the web sites they have signed up for before they change ISPs.
Instead:
You should consider allowing a user to provide multiple addresses, as well user-selected id and then let the user decide what they want they wish to do. Perhaps also consider allowing the user to provide an OpenID account.
CON: If I change my email address, suddenly all my account names are invalid. My name doesn't change, but my email often does. I have occasionally revisited a site after a number of years, and been stuck... what was my email address two years ago???
One setup you may want to consider: Have both a username and an email. The email is used to login and is always kept private, the username is used to identify the user in any public interaction, such as posting a comment. It winds up being slightly more secure as both halves of the user login credentials are kept private, whereas if you use a username for both login and public identification, half of the login is already known.
I definitely agree with you about having minimal registration for most cases, but depending on what you're doing you may want to balance that against added security for your users. Four fields isn't outrageous for registration, (username, email, password, confirm password), and if you're feeling particularly adventurous, you could cut it down to three by dropping the confirm password field, or two by emailing them a password that they can change later.
PRO
People hate having to create a unique name that fits their id and that has not already been taken to register for a site..So this is why the user id as EMAIL ADDRESS is so embraced.
ex:TStamper1930, who actually wants to remember 1930 at the end of my name that I really wanted
CON: If a hacker can try registering random email addresses en masse, he or she will be able to figure out which of those addresses are valid based on which registrations fail. This is a tactic that can be used to put together lists of known valid email addresses, which are a hot commodity on the spam black market.
Although now that I think about it, that's a problem that affects any website which asks for an email address as part of the registration process, regardless of whether or not there's a separate username. But it's still something to think about.
Stick to email addresses they are used everywhere, actually most of the major websites use them, they are unique so they save the user from struggling to find a name that's not used by others, also users won't forget their email addresses (in most cases at least :)), which is unlike usernames that they will keep on forgetting if they don't visit your site very often.
You shouldn't be worried about them being too long as all the major browsers (IE, FF .. etc) offer autocomplete to forms which is enabled by default, so you type the first letters in your email and you get a drop down list (ie. autocomplete list) where you just click to enter the whole email, personally I almost never type the email address in full, I always type the first letters then select the email from the autocomplete drop down list. Besides, if you allow users to be remembered (using a Remember Me checkbox and persistent cookies), it will be another reason to not worry about it.
I don't know about your app but usually users having multiple accounts is not desirable in most apps.
One con might be that if it's an email address the login can be guessed by people and brute force attacks attempted. Which is not really a big issue, since on most sites today the logins are publicly displayed.
The biggest pro is that logins are easier to remember this way.
A good setup is to require username and email. Allowing the user to login with either email address or username is very user friendly. An added benefit is the user can change their email address. It would also allow multiple accounts for one email.
To solve your con item of the email being too long to type in every time. I have implemented the StringScan Ruby library.
require 'strscan'
def signup!(user, &block)
self.email = user[:email] unless user[:email].blank?
str = StringScanner.new(self.email)
str.scan_until(/#/)
str.pre_match
self.login = str.pre_match
etc..
Then just change login method to allow either email or login to match password.
This works just like google or mobileme. A user can choose to just type in their email username (ie. username instead of username#gmail.com.)
I'm fighting with removing this right now. Here's a newer CON from the current era.
An email address is considered Personal Identifiable Information (PII) by many governments. Hence extra care needs to be taken any time you display it on a page, or even return it from an end-point.
Consider that many sites allow interactions between different users. This often means the site will provide a list of users to choose from (e.g. a drop-down list, or search results). This ca actually enable the leaking of PII by the site.
Usernames, on the other hand, can be completely anonymous. Given the prevalence today of password managers, users really don't need to actually remember their username and password.
If you don't care about forcing your users to login to your application with Facebook or some other social network (most people don't seem to care), then you can just use their social network email as their 'user id' when referencing other tables/documents (MySQL, Mongo, etc).
I've noticed the bonus to using social media logins is that all the security has been taken care of by said social network, including not allowing 2 users to have the same email or username in their database thus saving you the hassle of having to code for all of that. This is just my personal preference.