4 ms·
A much easier, and already widespread, way to prevent the problem described in the post is to use the email address as the login username. It is highly unlikely
by kijin 10y ago
A much easier, and already widespread, way to prevent the problem described in the post is to use the email address as the login username. It is highly unlikely that the same person will mistype the same email address every time he tries to log in, so the mistake will be caught very quickly even if someone else clicked the confirmation link.
If a person enters the wrong email address at signup, no damage is done. He can just sign up again with the correct email address. The account with the incorrect email address will either remain uncomfirmed and deleted at some point, or belong to someone else. Doesn't matter, it's an empty account. You should prune unconfirmed, empty accounts periodically anyway.
If you really want users to have a separate username, nickname, handle, or whatever, that's fine. But that should be separate from the login, especially if it's going to be visible to other users.
- chmike 10y agoSo when the db gets hacked all the emails are gone. Hello spamming.
- franciscop 10y agoIt is the same case as the one in the article, where the email has to be kept for resetting the account.
- chmike 10y agoYou are right. I overlooked that. It should be encrypted.
- saurik 10y agoThe "damage" that is done is that the user is doing things attached to their account and now they no longer have access to it when they try to come back later.
- kijin 10y agoUsers should not be "doing things attached to their account" until their email is confirmed. OP's suggestion is just an extreme version of the same principle, since it won't even allow people to set a password until their email is confirmed.
- Theodores 10y agoI am sure you can also get autofill to get the email address correct on popular devices for most people, therefore making the process fairly frictionless. Plus email address is a very good primary key.
- jsnell 10y agoEmail addresses are awful primary keys. Sure, it's unique. But the other main property of a good primary key is that it never changes. Email addresses change constantly. People use their work or university address for personal things, and then change jobs / are laid off / graduate. Or they use an email from their ISP, and move. Or they used to use one webmail system, and switch to one with a better UI; buy their first Apple device switch to an icloud email instead of a gmail one. It's fine to use an email address as the thing you enter into a login box. But internally you really want the user records to be keyed by something else, and just associate an arbitrary number of email addresses to that.
- zAy0LfpBZLC8mAC 10y ago> Sure, it's unique. No, it's not even unique.
- wolfgang42 10y agoIndeed, the ecommerce system at my company used to use email+password as the account identifier (because reasons) and when we tried to deduplicate we found a lot of duplicates were things like SmithFamily@isp.example.com where one account always shipped to "Laura Smith" and the other one always shipped to "Harry Smith".
- nommm-nommm 10y agoEmail addresses are a terrible primary key. They change (and they change a lot). They are longer than strictly necessary. A related problem there isn't a one-to-one mapping between email address and person, one person can have several email addresses. If you want to let a person have many accounts and keep track of which accounts a person has (like ebay does) then you're going to need a person primary key too and can't make an assumption about email = person. Its my opinion natural primary keys should be used very, very sparingly if at all. There's basically no "person" natural key. Even social security numbers are subject to various problems when used as primary keys. SSNs can (rarely) change. Laws and policies around SSN use and storeage also change.