[HN Gopher] "Invalid Username or Password": a useless security m...
___________________________________________________________________
"Invalid Username or Password": a useless security measure (2014)
Author : prmph
Score : 239 points
Date : 2022-11-23 12:12 UTC (10 hours ago)
(HTM) web link (kevin.burke.dev)
(TXT) w3m dump (kevin.burke.dev)
| danjc wrote:
| In 2022, building your own user signup/sign in flows is almost as
| bad as rolling your own crypto.
|
| Edit: a rebuttal is mightier than a downvote.
| [deleted]
| upofadown wrote:
| Usability always seems to lose to security. Then we complain that
| the users can't use the system.
|
| I have come to think that every decision of this sort should
| first be an attempt to increase usability. Security _is_
| ultimately about usability. They are not actually at odds. Too
| often there is no analysis done after a potential security issue
| is identified past directly resolving the issue. Rarely will
| there be an attempt to reevaluate the usability after the change.
| bluenotebo0k wrote:
| "99.9% of websites on the Internet will only let you create one
| account for each email address. So if you want to see if an email
| address has an account, try signing up for a new account with the
| same email address."
|
| Yes, but signing up is a more cumbersome process and usually has
| a CAPTCHA attached to it, unlike logging in.
| capableweb wrote:
| > Yes, but signing up is a more cumbersome process and usually
| has a CAPTCHA attached to it, unlike logging in.
|
| My guess of what is most common is that the actual trying to
| create a user in the backend/database is protected by a
| captcha, but checking if the email/username already exists is a
| separate endpoint that the frontend hits while filling out the
| signup form, before trying to create the actual user.
|
| But it's just a guess, and I can already think of many examples
| where that doesn't happen, which is for good reasons.
| justsomehnguy wrote:
| Yep. One site I infrequently visit moved from their own account
| system to the "check your email for a pass _code_ ".
|
| This just made me to visit and login even more infrequently.
| mod wrote:
| Half the web has a CAPTCHA just to view content. Thanks,
| Cloudfare.
| Sohcahtoa82 wrote:
| The only site that has ever asked me to solve a CAPTCHA
| before browsing content was pcpartpicker.com, and even that
| one stopped making me solve a CAPTCHA.
|
| Do you browse the web behind a VPN, Tor, or something else to
| hide your IP? That's been known to trigger CF's CAPTCHAs.
| mod wrote:
| Yes, it's my VPN triggering it. I run my own Wireguard on a
| DigitalOcean box, and I'm the only user--so not exactly a
| lot of bad traffic coming off of my IP (may have in the
| past, though).
|
| With the prevalence of Cloudfare now, it's pretty onerous
| to captcha every visit to a new site just because VPN. You
| would think Cloudfare could at least give me a "session"
| that persisted across the web, if they're going gatekeep
| the whole fucking thing.
| Sohcahtoa82 wrote:
| > I run my own Wireguard on a DigitalOcean box, and I'm
| the only user
|
| May I ask why you bother doing this? At best, unless
| Wireguard is also filtering your traffic, the only
| privacy you're getting is hiding your home IP address.
| Trackers will still track you by IP and build a profile
| based on it.
|
| > You would think Cloudfare could at least give me a
| "session" that persisted across the web, if they're going
| gatekeep the whole fucking thing.
|
| Yeah, that would make sense.
| mod wrote:
| I'm just tunneling, really. I prefer the logs on my WG
| box vs the local ISP and whoever else in-between. I don't
| think my webhost is really in the business of tracking
| down VPN users and selling out their browsing history,
| although it's possible. I do think my ISP probably is
| cashing in on people's browsing history, though, in some
| form or fashion.
|
| I use a pi-hole as well to block the trackers etc as much
| as possible, and so I don't leak DNS requests to the ISP
| either.
| rippercushions wrote:
| (2014)
| emodendroket wrote:
| This is a bit like the "don't write your passwords" stuff. It
| doesn't matter how obvious the arguments against it are -- the
| author of this piece is not the first to note the absurdity of
| this setup -- it is engrained as "best practice" and you will be
| fighting an uphill battle as a heretic trying to do anything
| else. I've lost similar arguments for similar reasons.
| baxtr wrote:
| _> Here is an actual UX /security tradeoff: you can make the
| signup process email based._
|
| Great. Now I can't share passwords any more with significant
| others. Instead I have to send them login credentials every time
| they want to login.
| capableweb wrote:
| Automatic forwarding solves this problem for you :)
|
| Personally I have my email setup so everything mentioning
| Netflix/HBO/Disney/$streaming-service/$shared-service gets
| automatically forwarded to our family inbox that everyone in
| the household has access to, in case they need to reset the
| password or do something related to those services
|
| Edit: added "automatic" to "forwarding" as that's the vital
| piece here
| baxtr wrote:
| Forwarding assumes I am checking email every time they want
| to login.
|
| The auto-setup is a cool idea though.
| capableweb wrote:
| Of course I meant "automatic forwarding" rather than
| manually forwarding everything, missed to add that word
| there someone, corrected :)
| Marsymars wrote:
| My approach is to have a shared email account for these
| situations.
| yegle wrote:
| Exactly! McDonald's (US app) is using a login system like this.
| Worse, they automatically log out all other logins once someone
| logs in on one device. Eventually I became the designated
| pickup person of my house.
| progval wrote:
| The author only recommends doing this on signup, ie.
| registration. Not on login.
| baxtr wrote:
| Thanks. You're right. Didn't read carefully enough.
| zajio1am wrote:
| > 99.9% of websites on the Internet will only let you create one
| account for each email address.
|
| Is it common? That seems like useless and impractical limit. E.g.
| for e-shops, one would like to have separate accounts for
| personal purchases and for business/corporate purchases.
| wccrawford wrote:
| Yes, it really is like 99.9% of websites.
|
| If you need multiple accounts, use multiple emails addresses, 1
| each. You should keep your personal and corporate email
| separate anyhow.
| toast0 wrote:
| It's kind of weird when you can login to different accounts
| with the same username, which is typically the email address. I
| mean, amazon lets you do it, and I've had two accounts with the
| same email address and password there; but it's still pretty
| weird. IIRC, I had two accounts with different addresses and
| changed them into the same address. A lot of accounts don't let
| you change your email address at all, so they solve the problem
| that way.
| drewcoo wrote:
| > Unfortunately this assumes that there's no other way for an
| attacker to discover whether a username/email address is
| registered for a service. This assumption is incorrect.
|
| The assertion is incorrect. Closing a means to account name
| guessing does not presuppose that there are no other means
| available.
|
| Locking my front door does not assume I have no other doors.
| exabrial wrote:
| I _used_ to think this as well. BUT, revealing _any_ information
| to attacker is a security problem.
|
| Take this scenario: Someone might not want their employer knowing
| they (legally) gamble online. The employer could simply browse to
| popular online gambling sites and probe the service with their
| email or username to see if an account exists.
| tromp wrote:
| I'd prefer the error to be "invalid username" if the typed
| username is not registered, and "wrong username or password" if
| it is. The system only knows if the username is valid or not; it
| doesn't know whether it's wrong (i.e. mistyped).
| kahrl wrote:
| I'd prefer to not create brute force vulnerability that leaks
| the site's list of user email addresses to an attacker.
| tromp wrote:
| As the article points out, this leaks it no more than trying
| to register an email address.
| throwawaaarrgh wrote:
| If we can't manage to make password managers standard, we should
| try to make them required.
| AtNightWeCode wrote:
| Would not go as far as saying 99.9% does this. A third-party
| pentest company we use does not consider this a security issue. I
| am not sure. I think it is information leak. I think the idea is
| that at some scale Everybody has an account so it does not really
| matter.
| est wrote:
| The best measure? Let any login pass, just generate a fake
| account if the credentials were wrong.
| TheMaskedCoder wrote:
| That would make things waaaay more difficult for users. "Okay,
| I'm logged in, let me do something.... Now it says I don't have
| permission?? Did my account get deactivated??? What am I doing
| wrong????"
| mrmattyboy wrote:
| Hah, I did this ages ago in notebook application that I wrote
| for myself..
|
| Though the amount of times I went a long time between logging
| in, got the wrong credentials and got scared very quickly when
| all of my notes had vanished :P
| patrakov wrote:
| The best measure? Ditch the password. It can be reset anyway,
| it can be stolen, it's just unnecessary complexity, it doesn't
| provide any security.
|
| You can prove ownership of the email? You can log in - worst
| case, after a password reset. So why have a password?
|
| email: ______________ [Log in]
|
| The "Log in" button results in a "Check your inbox and click
| the link in the email that we just sent you" page.
|
| Source: https://appear.in/ used this flow from the very
| beginning, before it was destroyed in a trademark dispute.
| EDIT: now it is https://whereby.com/user/login
| [deleted]
| t43562 wrote:
| Does it matter given that browsers can remember the
| username/password anyhow?
|
| On the other hand it's probably more important for user
| experience to encourage secure (long) memorable passwords rather
| than the fashion of impossible-to-remember short random ones. i.e
| I understand that something like
| "Iamafunnysailorwithalittlereddog" is better than "4kbjk5rv!"
| simply because length makes any password much harder to crack
| than the variety of each character.
| mod wrote:
| Length doesn't make it harder to crack, entropy does.
|
| Length is a good way to add entropy if the characters are not
| predictable.
|
| "Ava234ncqli3h23rn2f" is a lot stronger than "Ava234ncqli3"
|
| "DonaldTrump" is barely stronger than "Donald"
|
| Hopefully that makes sense.
| Sohcahtoa82 wrote:
| > "DonaldTrump" is barely stronger than "Donald"
|
| I mean, this is only true if you know your target is a raging
| Trump supporter.
|
| Obviously, that's a very cherry-picked example, but
| generally, length IS entropy, even if the characters are
| somewhat predictable when seen by a human, as long as you
| have no reason to predict the password based on the things
| the person likes.
|
| To give another example, "Inmyyoungerandmorevulnerableyears"
| is going to be an insecure password despite its length if
| your entire personality revolves around how much you like The
| Great Gatsy.
|
| On the other hand, something based on random words like
| "defaultsocksillegalinstalledconnections" is going to be VERY
| secure, despite how readable it is, because it's still
| gibberish and is long.
| geocar wrote:
| > Does it matter given that browsers can remember the
| username/password anyhow?
|
| No.
|
| The only thing that matters is having two public APIs: one that
| creates an account (failing if the account already exists), and
| another that checks if the password matches the username for an
| existing account. If you have those two APIs then there's no
| benefit to the second refusing to elaborate on whether the
| login is wrong or the password is wrong, and it _might_ be
| useful to users.
|
| However I'm not convinced. For many applications I think a
| better solution is to merge password-recovery with sign-up: Ask
| for the email/phone number, then send them an email to confirm
| which logs them in at the same time. _That_ link, then creates
| the account if it doesn 't exist. This way, no information is
| leaked, and you don't waste resources creating accounts that
| never get used.
|
| If you want a fully knowledge-based authentication system, you
| won't have password recovery, but you might not need usernames
| at all: I have an app like that, it uses webauthn/client
| certs/a couple other tricks to authenticate devices, and has
| one UI function to "log in on another machine" (by taking or
| displaying a QR code), a separate UI function to "share this
| view with another user" which creates the user (or selects an
| existing one that this user created), and a third function to
| add an existing user (using a meetme code). It only matters
| what users call each other, not that there are two (or more)
| geocar's in the system, and so the login API in this system
| doesn't need to differentiate between an invalid or expired
| code, nor can it reveal the existence of any internal account
| IDs because the client never actually sees them anyway.
|
| HN is a social space though, and in this case the username
| represents some kind of land reservation, so it _is_ important
| to know if land is taken before claiming it, and it 's in
| _this_ scenario I think I can agree that the login API should
| tell you if the username is wrong or if it 's the password. But
| I don't think Amazon or Shoprunner more should be like HN even
| if I usually like it here.
| fefe23 wrote:
| Oh boy. This is actually a good point.
|
| I guess having the nondescript error message has always been
| "best practices" or maybe it has crossed the road and has become
| cargo cult now.
| BeefWellington wrote:
| Not really. The points the author makes are only valid if you
| presuppose they are correct in that "account e-mails for a site
| are already public elsewhere", and that isn't a problem on its
| own.
|
| Many best practices are already what the author suggests: If a
| user signs up and doesn't already exist, send them an e-mail to
| confirm they own the e-mail. If that user already has an
| account, send their e-mail a message to the effect of "Someone
| tried to sign up to our service as you, is this you? If not,
| it's safe to ignore this message. Here's how to reset your
| password in case you lost that: ..."
|
| The thing the author is missing here is the same failure I see
| at a lot of companies: they take the approach that they're only
| there to protect their application, rather than doing what they
| can to protect the users of the application. Something as
| simple as knowing a user uses a service can become an easy
| spearphishing attack, for example, which the author doesn't
| mention.
|
| The general recommendations are good but defense in depth is
| key.
| yalogin wrote:
| A tangentially related question. I have, embarrassingly, not kept
| up with fido. What does it provide? I am guessing it provides a
| spec for a iOS keychain equivalent where passwords are stored in
| a dongle (or software) and "let out" based on user approval. I
| remember reading it also provides a new password-less auth
| mechanism. Is it out yet? If so is it adopted?
| joosters wrote:
| But the error message _can_ be true. If you mistype your
| username, you might have entered another, existing username. Just
| telling the user 'wrong password' will mean they are less likely
| to check that the username was correct.
|
| The website doesn't always know which one you got wrong, and
| assuming one way or the other just makes things worse.
| prmph wrote:
| > If you mistype your username, you might have entered another,
| existing username.
|
| That's a good point, but there is no way the website can detect
| that situation, and I suspect it is much less likely than
| typing your correct username and the wrong password.
|
| > The website doesn't always know which one you got wrong, and
| assuming one way or the other just makes things worse.
|
| If the website doesn't know which one you got wrong, then yes,
| it should just tell you so; the article is not arguing
| otherwise.
| dheera wrote:
| > there is no way the website can detect that situation
|
| Why? The website can salt, hash, match your password against
| all the hashed passwords for all the closest usernames within
| a certain edit distance.
|
| Not saying this is a good idea security-wise, but it's not
| impossible.
| prmph wrote:
| Apart from the security issues you've yourself noted, it's
| possible that the entered password matches another
| account's password coincidentally, not because the user
| intended to log in to that account.
| Dylan16807 wrote:
| If your account has the same password as another account
| that's 1 or 2 letters different, it's not really the
| site's job to protect you. You screwed up.
|
| This is not a very big problem security-wise. It makes
| online attacks slightly easier, but you can limit online
| attempts pretty easily. It doesn't affect offline
| attempts at all.
|
| The downvotes dheera got are extra inappropriate because
| they were just saying it's _doable_.
| herendin2 wrote:
| You can provide a more helpful error message by explicitly
| informing the user that the username they typed exists but they
| haven't offered the correct password for it.
|
| Unless the site searches to find out which username the entered
| password actually corresponds to (which is a whole new,
| terribly dangerous, can of worms), it can't do better than that
|
| Because any malicious player can easily check whether usernames
| exist, so hiding that data point is not much good for security.
| capableweb wrote:
| It doesn't seem like the author is arguing that just because
| you can instead validate if the email exists on a platform
| via the signup page instead of the login page, the vague
| message can be removed, but rather that the signup page
| should remove the information leakage as well, so there is no
| leakage anywhere.
| michaelmior wrote:
| That was presented as an option, but explicitly not
| recommended.
|
| > ...you _can_ make the signup process email based....I don
| 't recommend this, because of the context switches, though
| you can implement it.
| Xylakant wrote:
| practically all website that use an email as username
| nowadays require email confirmation, so already include
| the context switch. Because in the end, sending an email
| is the only way to verify that the email address is
| correct and you don't want an incorrect email address in
| your database if you rely on that communication channel.
|
| Now, if you have accounts in places where email addresses
| are not required and usernames take the place, the
| calculus may change. But using the context switch as an
| argument here is just weak.
| joosters wrote:
| I think that the author is saying that it is very difficult
| not to disclose that a user exists, and so there is not
| much point obfuscating it. Validating an email address on
| signup is only one way to 'leak' usernames.
|
| If you can obtain a user account on a system, then
| preventing checks for the existence of other users becomes
| much harder. e.g. if you have a login on a unix box, there
| are countless ways of discovering other usernames. Or a
| pathological case like reddit, where users have distinct
| URLs that are publicly visible.
|
| Or a messaging system where you can 'friend' other users -
| if you allow friend requests, what do you do if someone
| tries to contact a mis-typed username? Do you inform them
| that the user doesn't exist, or silently pretend that their
| request is awaiting a response that will never come? That
| paranoia will lead to a worse user experience.
|
| I think you can only really lock down the known user list
| on a very closed system, with few, trusted users, e.g. an
| admin control panel where you don't want to divulge _who_
| might have access to it in the first place. But that 's a
| very different scenario to a service open to the public.
| selykg wrote:
| Depending on your particular service, there's a better
| alternative for not leaking the existing account. A service
| I worked on previously was super sensitive and we didn't
| want to leak the existence of an existing account. What we
| did instead was asked for the email on the first page of
| signup, we verified the email was active by sending an
| email and a link to continue signup. If they already have
| an account we'd inform them in that email that they already
| have an account.
|
| This way, the attacker actually has to have access to the
| email in question to know that an existing account is
| present on the service.
|
| If you do the whole signup process on a single page and
| validate the email there then yea, you're gonna have a
| rough time.
| arm wrote:
| > _You can provide a more helpful error message by explicitly
| informing the user that the username they typed exists but
| they haven 't offered the correct password for it._
|
| The parent poster already addressed that though:
|
| " _If you mistype your username, you might have entered
| another, existing username. Just telling the user 'wrong
| password' will mean they are less likely to check that the
| username was correct._"
|
| If you inform the user the username they typed exists, the
| chance of them not thinking about double-checking they didn't
| mistype their own username increases.
| herendin2 wrote:
| >The parent poster already addressed that
|
| Thank you for your comment, but I don't agree
|
| "telling the user that the username they typed exists, but
| they haven't offered the correct password for it" - is
| extremely different from _Just telling the user 'wrong
| password'_. It's different because it provides more
| information
|
| >If you inform the user the username they typed exists, the
| chance of them not thinking about double-checking they
| didn't mistype their own username increases.
|
| That seems to be a user problem first of all, because it's
| based on the user's mistaken belief about the uniqueness of
| usernames. If possible, it would be best to help the user
| understand this.
| bombcar wrote:
| I remember some system on the coding horrors site or similar
| that would tell you "password already used" if anyone had it.
|
| That could allow "bad username" if you got the password right!
| comprev wrote:
| kuschku wrote:
| Again, how is that leakage, if you can just try registering a
| new account and see if that username or email already exists?
| cybrox wrote:
| ... which is a fixable leakage as well, as discussed in
| other threads in this discussion.
|
| Neither login nor sing up form should tell you that the
| account already exists.
| duxup wrote:
| Do most people who are throwing usernames and passwords at
| websites ... do that?
| michaelt wrote:
| If they could benefit from the 'information leakage' of
| knowing a username exists, they would do.
|
| If they don't - then maybe this 'information leakage'
| worry is obsolete security advice. There's loads of
| obsolete security advice around.
|
| (of course there might be other, non-account-security-
| related reasons to make it impossible to know if an
| account exists. It's one thing if HN's login form reveals
| that user duxup exists, it's another if find-an-affair-
| partner.com reveals the same thing)
| Dylan16807 wrote:
| There's another option, where trying to sign up takes
| more effort than trying to log in and leaves bigger red
| flags, so they won't use that method.
| duxup wrote:
| >There's loads of obsolete security advice around.
|
| Yeah that's kinda what I'm wondering about. It's possible
| that most of your security issues are just folks
| credential stuffing in the simplest way, if that's the
| case then the whole registration thing isn't really a
| realistic concern.
|
| Hell when I was in networking and if you did your best to
| just block traffic to / from specific regions / nations
| ... you eliminated a huge % of malicious traffic. For the
| guy thinking deeply about security that seems odd / not
| specific enough, but in the real world it works...
| joosters wrote:
| True, but the story covers that aspect - many systems provide
| other ways to check if a username exists (e.g. trying to
| register a new account, or sending an email to a gmail
| address, and so on)
| maxpro wrote:
| david422 wrote:
| The article literally tells how the username can already be
| validated.
| Supermancho wrote:
| > The article literally tells how the username can already
| be validated.
|
| The article says how many websites can allow that. This has
| nothing to do with the theory. This identifies poor
| implementations. These implementations trade reducing
| friction in signups, for some user security.
|
| There's nothing wrong with "Invalid Username or Password"
| (eg ssh, et al), unless the security mechanism is self-
| sabotaged.
| realgeniushere wrote:
| You could have bothered to read the article before posting
| the most obvious, dismissive thing.
| capableweb wrote:
| This is mentioned in the submission. The argument is as
| follows: If you're vague on the login page but still do the
| validation on the signup page, the information leakage
| happens regardless, just on the signup page rather than
| login, as most websites only allow one account per email.
| tluyben2 wrote:
| I just finish the registration process as normal but email
| the email that someone is trying to sign up again and if it
| is them.
|
| The user who signs up won't notice anything.
| Xylakant wrote:
| "If you're trying to prevent this information leakage, you
| also need to consider the following things" would be a much
| better conclusion to arrive at. Services that considered
| that problem just let you sign up twice and send you an
| email saying "you already seem to have an account." As a
| positive side effect, this also notifies the account owner.
| calibas wrote:
| That's a good argument for not letting the signup page leak
| information.
| [deleted]
| amelius wrote:
| If you just say "invalid username+password combination", then
| you can have both security and a correct message.
| ARandumGuy wrote:
| How big of an issue is it to leak this information?
| Disregarding the fact that many sites easily leak this info,
| how much security is actually gained by obfuscating what
| usernames are taken?
|
| It seems to me like two factor authentication, rate limiting
| logins, good password rules, and properly securing passwords
| provide much better security then obfuscating usernames.
| There's always a balance between security and usability. I
| don't think hiding username availability provides enough
| security to justify the harm in the user experience.
| hairofadog wrote:
| On this topic, I've noticed a lot of sites have split their sign-
| in forms into a two step process (submit username, then submit
| password). Does anyone know what this achieves? It seems like it
| would be trivial for an automated script to submit the form
| twice, but as a human I often have to open 1Password multiple
| times to navigate the process.
|
| For example: https://myaccount.nytimes.com/auth/login
| dexterdog wrote:
| 2-step signins are so annoying for those of us who don't use
| it. I imagine they are also annoying for people who use it
| because they still have to first type in their email address
| instead of just going to the google/fb/apple/etc page where
| they click on their identity.
| d8c6c050cb0a4d7 wrote:
| This is useful when you have multiple methods to authenticate.
|
| Maybe this user should be redirected to an oauth2 identity
| provider or maybe they should enter a password.
|
| Good implementations of this will have a hidden password field
| for password managers to fill along with the username. You'll
| still need to press enter twice though.
| tpetry wrote:
| This is for SSO reasons. When you enter your email address they
| check whether SSO is activated for your email address (or whole
| company domain) and will redirect you. It is better for
| usability than requiring your users to enter some random
| password or keep the password input empty.
| swhitf wrote:
| Usually it is to detect the user is registered to (or their
| domain is mapped to) an account with SSO or Social Auth and
| prompt them for that login mechanism. If the user is being
| required to go via the SSO provider, it makes sense to ask for
| the email first before they input their password so that they
| can be redirected it neccesary.
| ad404b8a372f2b9 wrote:
| I agree with the premise but the solution has UX issues of its
| own.
|
| Some users, like me, have learned to use the registration form as
| an account checker for their own email. I don't remember if I
| have an account on some websites, and if I do I don't remember
| with which email+password combo, and the password reset page
| doesn't tell whether the email is correct, and it often takes 10
| minutes for them to send a reset email so I still don't know
| whether I'm registered with the email I entered and should just
| wait or not registered at all and no email was sent. So instead I
| just try to register and bam, instant answer.
|
| In addition to that, the context switch to emails increases
| friction significantly during registration. It's much easier for
| the user to be logged-in immediately and not have to check their
| email. That's not even taking into account the wasted time of
| having to re-enter all your info.
|
| Disclaimer: I know the first issue is solved with a password
| manager and a faster email service, that's not the point.
| thomastjeffery wrote:
| You might not know if you have an account, and you might not
| remember your password. The solution to either problem is the
| same: send an email.
|
| So why not merge the two processes? Actually, any "forgot
| username/password" link effectively does this already. The only
| thing we need to do is make that more obvious.
|
| I think the easiest way would be to separate username creation
| from password creation. Just have a single sign-up prompt
| asking for an email address, and put the link to the password
| creation page into the sent email.
|
| Set the title/content of the email to clearly show whether an
| account exists already (with a password reset link) or doesn't
| (with a password/account _creation_ link).
|
| If the user stops there (the account creation email answered
| their question: they don't have an account with this email),
| then you can simply expire the password-set link without ever
| creating the account.
| ad404b8a372f2b9 wrote:
| It's not a solution to the problem I described, if it were
| the forgot password page would already solve it.
| thomastjeffery wrote:
| > it often takes 10 minutes for them to send a reset email
|
| That's the only part of your description I can see that I
| didn't account for. For any of this to work, the email must
| be sent quickly.
| ad404b8a372f2b9 wrote:
| Yes that's a crucial part of the issue, because many
| websites send their emails very slowly. So the lack of
| email can mean both:
|
| "No account for this email"
|
| "Yes, there is an account for this email but it'll become
| apparent much later"
|
| And your website might send emails fast, but that won't
| solve the issue because as a user I don't know if your
| website is fast or slow, so if I'm not registered with
| the email I entered, I'll see no email in my inbox and
| I'll have to assume it's one of the slow websites and
| wait 10 minutes refreshing to be sure.
|
| That's why as a user I use the sign-up form to check if I
| already have an account instantly, and I'd be
| dissatisfied by an email-based system.
|
| I guess it's for the website admins to weigh ease of use
| against security, but I feel often using email worsens
| the U.X in a way that's not justified by the security
| benefits.
| thomastjeffery wrote:
| There's only one UX path that doesn't involve email,
| apart from just logging in, and that's when you _do_ know
| the password, but _don 't_ know the email. In that case,
| you probably only have few enough email addresses to try
| that that isn't an issue.
|
| In every other path, you will definitely be waiting
| (hopefully not long) for an email, so what does it
| matter?
| ad404b8a372f2b9 wrote:
| Imagine you're an average person and you have 3 emails
| and 3 passwords that you typically (and repeatedly) use,
| in any combination. (That's pretty much every non-
| software person I know, and me on every site before I
| started using a password manager)
|
| To login you have to try 9 combinations, but your account
| will be frozen after 3 wrong tries.
|
| The log-in screen does not tell you whether you have the
| wrong email or the wrong password.
|
| With the sign-up screen you can immediately know which
| email you used, then you only have to try the 3
| passwords, and then you're in.
|
| If you don't remember the password you can go to the
| forgot password screen and be confident you'll get the
| reset email, since you know the right address to enter.
| martius wrote:
| There is also the question of leaking whether a given user has an
| account on a website or not.
|
| Maybe I don't want my employer to know that I have an account on
| competitor-service.com, or my partner to know that I have an
| account on kinky-thing.website.
|
| It might not be a security issue, but it could be a privacy
| issue.
| sgjohnson wrote:
| > Maybe I don't want my employer to know that I have an account
| on competitor-service.com, or my partner to know that I have an
| account on kinky-thing.website.
|
| In that case, maybe employ the basic opsec measure of having a
| separate email account for competitor-service.com and kinky-
| thing.website?
| bombcar wrote:
| For the vast majority of people, this is a bridge too far.
|
| It _is_ an advantage of using things like the apple-generated
| randomized emails for accounts.
| martius wrote:
| Sure, but if we are talking about improving user experience,
| I don't see how this helps.
| sgjohnson wrote:
| OPSEC and user experience are completely unrelated things.
|
| If you have something to hide (from anyone at all), you
| have to employ opsec measures. Using an email account that
| can't be immediately linked back to you is the most basic
| of them (and would be perfectly sufficient in the scenario
| described).
|
| It wouldn't even matter if the website didn't leak in any
| way that an email is registered with them, because data
| breaches happen, and should one happen, you'd be fucked
| from that perspective anyway. Remember the Ashley Madison
| leak?
| martius wrote:
| Are they unrelated?
|
| The article is about a tradeoff between security and user
| experience, claiming that a given practice is bad
| experience without any security gain.
|
| The Ashley Madison leak shows that there are plenty of
| vulnerable users who are not educated to even "the most
| basic" things to do to protect their privacy.
|
| It's also a question of user experience to protect users
| against themselves, or against threats they don't know
| about.
|
| Saying "it's up to the user to do the right thing" isn't
| really helpful in the context of discussing account
| creation/login UIs.
| sgjohnson wrote:
| > Are they unrelated?
|
| Perhaps not when considering only the points made in the
| article, but in the grand scheme of things, yes.
|
| If you're worried about your opsec (not the sites, and if
| you're worried about your opsec, you should treat the
| site as having no security measures whatsoever), ux is
| secondary to you, because in the case of a leak you
| should be in a position where you can plausibly deny
| everything. And you shouldn't expect the site to help you
| with it.
| Xylakant wrote:
| While I agree in general that this is the better way,
| it's in the end out of the sites control. The could
| notify the user, but cannot implement any measures that
| can help to protect the user. Avoiding information leaks
| is under the sites control - you just need to consider
| whether you can truly avoid this leak.
| sabellito wrote:
| The author explains in the article that you're not protected
| from that case either, as the attacker can try to sign up with
| your email and find out anyway if that email is already
| registered.
| bombcar wrote:
| He gives a solution for that and says it is "too cumbersome".
| dschooh wrote:
| Not necessarily. You can design the sign up process by way of
| always ending with a message that says you will be notified.
| Xylakant wrote:
| Many services let you sign up with an existing email and just
| send a "you tried to sign up, but you seem to have an address
| already." to the account owner. In that case it's
| indistinguishable for the attacker.
|
| Many services already require email confirmation to finalize
| the signup process so the extra effort is low.
| wongarsu wrote:
| And those services also plug the forgotten-password
| information leak by just informing you "if you have an
| account, you got an email" instead of giving you an
| explicit success or error message.
|
| I guess the better point for the article would be "many
| websites cargo-cult the login error message without
| understanding why it's there and how that should impact the
| rest of the service"
| prmph wrote:
| > And those services also plug the forgotten-password
| information leak by just informing you "if you have an
| account, you got an email" instead of giving you an
| explicit success or error message.
|
| This might be a better approach, but one problem I see
| with it is: what if the email is not actually delivered
| because of an internal bug in the website? How would
| users know they didn't receive an email they were
| supposed to have received, and take the appropriate
| action (trying again or contacting help), versus that
| they entered a wrong or unregistered email?
| SoftTalker wrote:
| Email might not be delivered for many reasons that may
| not all be in control of the sender. It may be classified
| as spam somewhere along the way. It may simply drop into
| a black hole. Eventually the user will try again.
| asddubs wrote:
| sounds like a nightmare for someone who forgot their
| password and has multiple emails, and isn't sure which
| one is right. did i use the wrong email, did it land in
| the spam folder, or did my email provider just quietly
| delete the email (which unfortunately does happen, and
| not just with dodgy emails/IPs)
| Xylakant wrote:
| I have multiple emails, and this never turned out to be
| an issue - worst case i just try all of them.
|
| But if you want to improve the implementation, the
| provide can also decide to send an email in case no
| account is registered with that email address - "Hey,
| someone tried a password reset for this email, but
| there's no associated account. If it was you, ..., if
| not, ignore this email."
| pmontra wrote:
| Those sites probably prompt the attacker with a "We have
| sent you an email with an activation link" and the owner
| receives the "you tried to sign up, but you seem to have an
| address already" message. In this way they don't leak
| anything to the attacker.
|
| By the way, I've been stuck for years with an ecommerce
| site that thinks I already registered with them using my
| email. They're telling me that I must activate the account.
| I click the link to send me the activation message again
| but then they say that my email is not registered with
| them. I'm still stuck and will probably never buy from them
| because I can't.
| ohbtvz wrote:
| I'm confused, you've been trying to buy an item from that
| website for _years_ and it never occurred to you to just
| use a different email address? This isn 't really
| believable.
| prmph wrote:
| With this approach, I imagine slightly less technically
| savvy users might be confused as to whether a new account
| was actually created before they were also informed of the
| old account. In other words, they might not know if a new
| password they entered is also usable for the original
| account.
| darkwater wrote:
| Off the top of my head, I cannot remember any site I use
| that works that way (which is also basically what TFA is
| suggesting to do as a trade-off implementation)
| pmontra wrote:
| Xylakant explains how to cope with that in a sibling comment.
| Note that email is personal information often containing
| name, surname and maybe a likely year of birth
| (johndoe92@example.com). Leaking it is not OK in several
| legislations so we should take special care before telling
| someone that some person is or is not in our database.
| bombcar wrote:
| This is a huge problem - if I know your email, and can get the
| error pages, I can find out where you have accounts; sometimes
| I can even find out the account _name_ with that.
|
| Even worse with phone numbers.
|
| If you want to confirm a user is the same as another user on a
| different site, and you know their phone number, often part of
| the recovery process will reveal part of the phone (a text has
| been sent to * _-*_ -*33, eg).
| truculent wrote:
| > Unfortunately this assumes that there's no other way for an
| attacker to discover whether a username/email address is
| registered for a service. This assumption is incorrect.
|
| > 99.9% of websites on the Internet will only let you create
| one account for each email address. So if you want to see if an
| email address has an account, try signing up for a new account
| with the same email address.
|
| This point is undermined by the sign-up workflow informing of
| whether an account is registered under a given username.
| hutrdvnj wrote:
| That depends on the sign-up workflow. It is possible to not
| provide the information "user already exist" on sign-up and
| instead just say "we sent you an email, please confirm". In
| this scenario a potential attacker who just wants to check
| for existing email addresses has no access to the email
| addresses he wants to check.
|
| The contents of the email could be something like "Hey you
| just tried to register with this email address, but we
| already have an existing account with this email address ...
| Was that you? ... Maybe you have forgotten got your
| password?"
| janalsncm wrote:
| Is there a use case for passwords at all? Passwords have the
| downsides of being guessable and hackable, as well as forgotten.
| I'd like to avoid the "correct horse battery staple" malarkey if
| possible.
|
| In most cases, control of the account email is equivalent to
| control of the account because I can reset the password if I
| control the email. So it seems that magic links or OTPs are
| strictly better. Am I missing something?
| djaychela wrote:
| I think you are, yes. These situations spring to mind, all of
| which make email OTP a worse solution imo:
|
| Shared account without both having access to email.
|
| Email OTP is more time and effort than entering a password.
|
| Email can be down.
|
| You may not have access to email for another reason (different
| device, etc).
| nerf3000 wrote:
| I don't think saying "but these popular sites let you enumerate
| registered email addresses via this other form" is justification
| to be lax about protecting against user enumeration attacks on
| your own site.
|
| The actual take away should be more like "I found a security
| issue in the registration form of these popular sites, they
| should fix it"
|
| Enumerating valid emails, even if rate limited, lets an attacker
| build a contact book for targeted phishing attacks, connecting
| leaked passwords, brute forcing and is also useful in recon to
| determine what sites a person may have an account with, and more.
| It's worth protecting against as much as possible.
| ericalexander0 wrote:
| I've worked in infosec for over 15 years. I've built security
| programs from the ground up at two companies.
|
| I've learned much of compliance/security is cargo culting and/or
| streetlight effect, if not radicalized.
|
| You can debate the standards, just like you can debate with your
| retired uncle who watches way too much fox news.
|
| The better solution is to find good enough solutions that let
| infosec teams check their boxes and move on to more important
| work.
| dubbel wrote:
| This is assuming that the service allows new users to sign up
| themselves. Also, testing it via signup sends a lot of emails to
| the victim (if the attacker tries a number of services), so the
| victim at least knows that something is up.
| allknowingfrog wrote:
| That was my first thought as well. The application that I
| maintain is invitation-only, so I think the rest of the
| argument is irrelevant to me.
| ohbtvz wrote:
| I'm not sure what this brings to the conversation. I don't
| develop any web application, so the rest of the argument is
| also irrelevant for me. Should I broadcast that everywhere?
| mjochim wrote:
| It brings to our attention that there is a whole class of
| applications - "invite only" ones - where the main argument
| of the article does not apply. And therefore the conclusion
| ("The login user interface should distinguish bad user
| handle vs bad password") does not apply either. The article
| just mentions "99.9% of all websites" somewhere near the
| beginning, and that number may be way too high.
|
| I would in fact be interested in an analysis of how many
| web sites do and don't follow recommendations like "do NOT
| distinguish bad user handle vs bad password", which are
| widely considered best practices. I wouldnt take a guess,
| could be anywhere between 10 and 90 percent.
| gumby wrote:
| Related question: what's the deal with having a login form that
| only takes a username, and then only shows a password field after
| you've pressed enter? I find this very annoying and can't come up
| with a benefit.
| danjc wrote:
| SSO handoff as a sibling points out but also once email is
| known, a determination is made about trust level for the sign
| in attempt. Cookies, IP and other fingerprinting are used to
| determine whether single or double factor auth is required.
| kozziollek wrote:
| If username is an e-mail then an app probably checks if e-mail
| domain has configured single sign on (SSO) and, if it has, it
| redirect you to your company authentication server instead of
| asking for password.
| switch007 wrote:
| Another reason to use unique email addresses for each service is
| that it's almost impossible for someone to discover if you've
| already signed up
| dang wrote:
| Discussed at the time:
|
| _"Invalid username or password" is a useless security measure_ -
| https://news.ycombinator.com/item?id=8683003 - Dec 2014 (182
| comments)
| MostlyInnocent wrote:
| The article makes a good point, were it not for security auditors
| (SAs).
|
| SA: You leak information and therefore violate policy by
| disclosing on the login form whether an account exists or not!
|
| Me: Yeah, but figuring out if an account exists is really simple
| anyway: just a query to a different endpoint...
|
| SA: NEVERMIND, MY LAD: disclosing account existence upon login
| violates BEST PRACTICES!
|
| Me: OK, yeah, whatever, we'll just change the error message to
| "something you may or not have entered may or may not be valid
| information, try again, or not"
|
| SA: cool beans! WE ARE NOW INDUSTRY LEADERS
| Terretta wrote:
| Every well known credit card / credit data breach has been of a
| PCI-DSS compliant party.
|
| To any SAs reading this: you're not secure because you're
| compliant.
| hkopp wrote:
| The argumentation is faulty.
|
| Users cannot be enumerated using the login, but using the signup.
| The author then argues that they should add the user enumeration
| function to the login.
|
| This is similar to: The door is locked, but the window is open.
| And then consequently it makes no sense to close the door at all,
| as an attacker can sneak through the window.
|
| Instead, the window should be locked as well, i.e., it should be
| impossible to enumerate users with the signup function.
| darrinmn wrote:
| > 99.9% of websites on the Internet will only let you create one
| account for each email address. So if you want to see if an email
| address has an account, try signing up for a new account with the
| same email address.
|
| This is not true if the signup flow is implemented correctly.
| Signing up for an account should always respond with the same
| message "we sent an email for you to confirm your account
| signup". The owner of that email address then receives an email -
| either 1) normal signup process, or 2) "did you just try to sign
| up? You already have a valid account for this email address."
|
| This way you cannot tell via the signup web form alone whether an
| account exists or not. You need to have access to the email
| address.
| Beldin wrote:
| True. Moreover, _even if_ a site implemented this in a naive
| way, they made the UX much worse for the attacker. And that
| constitutes a significant issue, if we follow the reasoning of
| the article.
|
| It does, actually: it hampers casual attackers -- those looking
| for any account in. On the other hand, attackers out to break
| into a specific account will not be deterred. Then again: they
| are not deterred in either case, so you might as well go with
| the version that impacts some attackers.
| akerl_ wrote:
| Sure, I guess? But the overwhelming majority of sites on the
| internet do not do this. Primarily because their new signup
| flow has priorities that matter an order of magnitude higher
| for them than avoiding leaking whether an account already
| exists.
| dwheeler wrote:
| Exactly, if you reveal that an account exists when you just
| type in an email address, then you have a privacy failure and
| probably a security failure.
|
| For example, the OpenSSF's secure software development
| fundamentals course <https://openssf.org/training/courses/> in
| its section on minimizing feedback
| <https://github.com/ossf/secure-sw-dev-
| fundamentals/blob/main...> says:
|
| * If a user tries to create an account using an email address,
| don't tell the user if an account with that email address
| already exists. Similarly, if a user tries to do a password
| reset using an email address, don't tell the user if there is
| no account with that email address. Providing that information
| would allow an attacker to determine if a specific email
| address is being used (or not) by some existing account.
|
| Now for the unpopular take: not everyone lives in the US. The
| GDPR requires protection of personally-identifying information,
| and in many cases that includes email addresses that identify
| individuals. There are exceptions, but it's typically better to
| keep email addresses private unless the user specifically
| authorizes it.
| [deleted]
| lhnz wrote:
| If you did implement it like this it would be helpful to
| receive an email telling you that somebody has tried to re-
| register the email address you already have an account with.
| thomastjeffery wrote:
| That's the option #2 they described.
| Al-Khwarizmi wrote:
| In simple registrations this is fine. In multi-page
| registrations with long forms, it can waste the user's time by
| making them input all the data again when it wasn't needed,
| though.
|
| Except in really critical applications like payments, etc., as
| a user I'd rather have the convenience of being warned early
| about already having an account that the little extra security.
| Xylakant wrote:
| How often does it happen that you fill out a multi-page
| registration form just to notify you that you already have an
| account? I rarely bump into the issue of already having an
| account that I forgot.
|
| Is saving that extra amount of work in a rare case a concern
| in practice? Sure, it would annoy me a bit if it happened to
| me, but I'd be more like "man, I'm stupid" instead of "man,
| this site is stupid, I'll never go there again."
| Al-Khwarizmi wrote:
| It has happened to me sometimes with ecommerce websites
| that I only use once every few years.
|
| Only a mild annoyance, but still more annoying than it
| would be to have someone access my account on such websites
| (which would be basically negligible, as I don't store
| payment information there, and you have to multiply it by
| the also negligible probability that the information leak
| from the login form is key in letting the bad dudes access
| my account).
| thomastjeffery wrote:
| You shouldn't be doing long web forms _before_ creating an
| account anyway.
| layer8 wrote:
| This is commonly the case for online shopping, where
| account creation is optional and may only occur after
| confirmation, but the order will be placed regardless.
| darrinmn wrote:
| See my comment
| https://news.ycombinator.com/item?id=33720405
| thomastjeffery wrote:
| But in that case, there is still an account (just without
| login ability), and you are probably even sending an
| email.
|
| So in the email you can include a link to optional
| account (username/password) creation.
|
| And if you aren't sending an email, then the user has
| clearly decided not to create an account.
| layer8 wrote:
| The problem is if an account for that email already
| exists, see
| https://news.ycombinator.com/item?id=33720063.
| zhfliz wrote:
| You shouldn't be taking my email just to demand lots of
| information from me after I already gave my email to you.
|
| If you demand lots of information that should be clear
| right away.
| [deleted]
| TeMPOraL wrote:
| So now you're saying web UX should actually improve and
| give up the major disadvantage it has over paper forms:
| hiding the full flow from the (l)users.
|
| /s, but only slightly.
|
| You're right, of course. The answer is the one nobody
| wants to hear: you can tell users what you'll want from
| them, then ask to create an account, _and then_ ask them
| to do the things you outlined before registration.
|
| As for multi-page forms, they make sense if you target
| non-JavaScript use, but if your site is already an SPA,
| you might as well present the form in full, and
| conditionally disable parts that don't apply based on
| earlier inputs. This is the way to improve over the paper
| UX.
| thomastjeffery wrote:
| I can sympathize with your frustration about long web
| forms, but that seems to me like a separate issue with a
| separate solution.
|
| People shouldn't be making long forms part of account
| creation unless absolutely necessary; in which case it
| should already be obvious to the user that it is.
|
| If it's somehow necessary but not obvious, you can put up
| a friendly warning. Maybe something like, "Step 1/12" or
| "expected registration time 15min."
| [deleted]
| metacritic12 wrote:
| While clever, this system has UI tradeoffs, if I need to break
| my signup flow in order to click on a link and return to the
| signup page.
|
| I believe this is also non-standard right now.
| prmph wrote:
| Could you please elaborate? What's the standard best practice
| for signup now?
| darrinmn wrote:
| Are you saying your signup flow would automatically log the
| user in without confirming their email address (verify
| later)? I wouldn't suggest that for most websites as that
| would allow someone to signup with an email address they
| don't own.
|
| For most websites transacting with potentially sensitive
| information, having an email sent to confirm you own the
| email address should already be part of the normal flow, so
| I'm not suggesting any extra step here. I was only suggesting
| an alternative email response in the situation you try to
| signup with an email that already exists. The normal happy
| path signup flow for a new account is not affected at all by
| my comment.
| metacritic12 wrote:
| I think the sibling post by samwillis explains my view the
| clearest.
|
| Basically, the business case for breaking the signup flow
| to require users to check their email is low. It interrupts
| flow and reduces conversion rates.
|
| The suggestion then is yes, you are allowed to use emails
| you don't own to sign up for an account. The reason this is
| allowable is that who would want to do it? The account
| would be broken and the real owner of that account can pop
| your password.
| cozzyd wrote:
| well, a user might put in the wrong email by mistake...
| gohohn wrote:
| Another method is to delegate the registration and login flow
| to external providers, using OAuth.
|
| If you have to log in to a website via one of Microsoft,
| Google, Facebook, Twitter, etc. then, if implemented properly,
| there's no way of knowing if an account associated with this
| external identity exists already.
| mint2 wrote:
| Giving in my Facebook that centralized view and extra data...
| no thanks. Same with Microsoft and google.
| gohohn wrote:
| The only information they would receive is that you signed
| in to a specific website.
| godshatter wrote:
| Most of those are trying to track me around the net for their
| own purposes. I'm not volunteering any extra information for
| them to profile me with. No thanks.
| gohohn wrote:
| The only extra information you would be volunteering is
| that you signed in to a specific website. In most cases,
| this is not really a big deal.
| MichaelCollins wrote:
| > _this is not really a big deal._
|
| If it's not a big deal, then why do they offer this
| service "for free"?
|
| It's all part of their commercial panopticon. You're
| missing the forest for the trees.
| godshatter wrote:
| If I don't want them knowing I surfed to somewebsite.com,
| why would I want them to know that I actually logged in
| to someotherwebsite.com?
|
| I get that people have different levels of trust for
| these services than I do. I'm just more cynical than
| most, I guess.
| bombcar wrote:
| You are also trusting the Oauth provider to never login
| as you for their own inscrutable purposes.
| gohohn wrote:
| That is true. But then many people put a lot of trust in
| the major providers in many other areas too, such as
| hosting their private files and email, holding card
| payment information, and so on.
| bombcar wrote:
| Yeah an email provider is basically Oauth with extra
| steps for ALL your accounts.
| MichaelCollins wrote:
| Absolutely. In the case of Facebook, it's easy to imagine
| them logging into websites as you to slurp up your
| contact list on that site. Don't worry, you agreed to it
| somewhere in the thousand pages of small print!
|
| Or as the case of twitter demonstrates, you're also
| trusting all future owners of the Oauth provider, whoever
| they may be. If an erratic billionaire with a penchant
| for breaking the rules whenever it suits him buys your
| Oauth provider, who's to say what he'll do with his new
| access? He could treat your accounts as his personal
| toys. Better hope you don't earn his personal ire when
| he's on another wine and ambien bender.
| samwillis wrote:
| The vast majority of the time the number one priority is
| reducing friction before a conversion. As much as a email
| confirmation prior to completion is more secure, the business
| case is far less strong.
|
| Customers can fix their email later, they can contact customer
| support if they got something wrong.
|
| Get them in the door ASAP, and either using the account, or
| complete an order. Don't redirect them to their email where
| there is a good chance they will either get distracted or the
| email will be delayed.
|
| That's not to say you shouldn't also have your own measures in
| place to detect errors, or malicious checking if an email is
| associated with an account.
| MichaelCollins wrote:
| If reducing friction is the priority, then maybe skip email
| completely. Let people sign up with any username and don't
| require an email at all, like HN allows. Most sites that
| require an email don't _need_ an email, and only ask for it
| so they can spam users with nonsense like product updates.
| blacksmith_tb wrote:
| I'd say that depends on what 'a conversion' is - if it's
| buying physical things (and getting shipping confirmations
| for them), an email is maybe not absolutely required, but
| most of your customers would probably still rather they got
| those?
| MichaelCollins wrote:
| Maybe they want SMS updates to their shipping, does that
| mean you should ask for confirmed phone numbers on
| signup? Of course not. Let them enter their email or
| phone number for shipping updates when they're confirming
| their purchase.
|
| Ideally you shouldn't require users to make an account to
| make a purchase at all. There should be a "guest" path
| for purchases. Some sites still get this right. I can buy
| anything from plane tickets to pizzas without having an
| account on the company's website. Meanwhile half the
| "Show HN" non-commercial toy websites I come across seem
| to require a confirmed email for no good reason at all
| (probably because the webdev is hoping his little toy
| website somehow becomes a real business, and then he can
| spam my inbox with updates about this and turn me into a
| paying customer.)
|
| Off the top of my head, here are some companies that
| don't require me to confirm my email address when making
| a purchase or an account: Southwest Airlines. Dominos
| Pizza, Hacker News, Reddit.
|
| If those guys don't need a confirmed email address,
| probably your site doesn't either.
| quacksilver wrote:
| Could part of the pattern for requiring an email address
| (or phone number) at time of purchase be reduced customer
| support costs for the vendor.
|
| With an email address the customer can reset their own
| password for using their account with self service
| features - like get a duplicate invoice or
| view/change/cancel a reservation or similar stuff.
|
| Without an email address / phone number / something to
| link a customer to their order, the customer will need to
| phone up a call centre or visit a store or use live chat
| to get what they need.
|
| Southwest probably have a call centre or live chat
| anyway. Dominos have stores (and presumably a customer
| service department) and a pizza order is probably only
| interesting for a short time.
|
| If the customer can't sort their order out or get it
| sorted out, they will complain or give bad feedback. Even
| if it was their choice not to leave an email as they were
| too busy.
|
| Your business without any of these things has no
| incentive to get them if it can just collect emails
| instead and let users use self service features. Even if
| you already have call centers / live chat / stores then
| your cost of dealing with the customer via a self service
| portal is probably way cheaper than using them.
| Alupis wrote:
| These are not good examples of everyday websites.
|
| Southwest Airlines knows an awful lot more information
| about you than you provide them. They don't need your
| email address because they know who you are - and they
| make it your responsibility to monitor changes to your
| schedule/flight.
|
| Dominos Pizza allows you to monitor in real time the
| status of your delivery on their website after checkout.
| You can provide an email address to access the tracking
| status page again if you close it.
|
| Hacker News is not a good representation of anything
| outside of a very tech-focused forum. It's designed to be
| anonymous, there is nothing to keep track of (order
| status etc) and if you lose your password to HN, you
| might just be SOL. That's not going to fly for the
| general public.
|
| Reddit is focused on eyeballs and clicks - nothing else.
| You're not buying things on Reddit and waiting for them
| to deliver to your house or whatever. Reddit just needs
| you to click and look at things to make money. Reddit
| also requires an email address, but if you don't provide
| a real one then you're SOL if you lose access. Again, not
| going to fly for the general public.
|
| The reality is, most regular sites do need a reliable way
| to contact you for business reasons. Some are even
| required to have your contact information (for
| international shipments, as one example).
|
| Your email inbox does a good job of holding emails for
| you, so let's stop pretending it's a huge burden to get
| an email... and if you find your way onto some newsletter
| list just click the unsubscribe button. It's not that
| hard...
| MichaelCollins wrote:
| > _The reality is, most regular sites do need a reliable
| way to contact you for business reasons._
|
| In these cases, which I think are more unusual than
| usual, a email can be required during checkout. There's
| almost never a valid reason to require a confirmed email
| account during account creation, before the user has even
| decided if they want to make a purchase.
| Alupis wrote:
| We might be envisioning very different types of websites
| then. Some random dude's blog - no you don't need to
| enter your email address.
|
| Buying something online or subscribing to a service? The
| company does need a way to contact you... which is going
| to be email.
|
| Email addresses are more-or-less globally unique, which
| makes them very handy for identifying an individual
| customer. Verifying the email address is an extra step
| that can provide the business with more confidence when
| dealing with a new potential customer. Certain types of
| fraud vanish or are greatly impeded with email
| verification, such as carding attacks. Customer support
| tasks can be performed more reliably and with identity
| confidence of who they are dealing with, stopping account
| impersonation attacks and more.
|
| With all that said, sites that choose not to verify email
| addresses put a greater burden onto the customer for
| support needs. Password resets, order tracking,
| cancelling subscriptions etc. all become more difficult
| if the email address entered by the customer had a type-o
| for example, or belongs to someone else.
|
| That doesn't mean all sites should verify email addresses
| - but it does mean railing against any site that does is
| misguided.
| MichaelCollins wrote:
| Twitter or discord, why do these require me to confirm an
| email or phone number when reddit doesn't? Why do shop
| websites like Etsy require me to confirm my email address
| before I even decide to purchase or sell anything? If
| you're worried about credit card fraud, confirm my
| identity when I give you my payment info, not when I'm
| merely registering an account.
| Alupis wrote:
| What you propose would lead to increased cart
| abandonment. No business wants that.
|
| Account registration is the perfect time to do email
| verification, if the business is going to do it. The user
| already is in that "mindset"... and clicking a link is
| really not very difficult. Everyone in that flow
| understands what is going on.
|
| Sites like Etsy probably have a significant fraud
| problem... and as previously discussed verifying email
| addresses goes a very long way towards minimizing risk.
|
| Companies like Twitter and Discord likely require
| verification for the same reasons - fraud/abuse. I am
| aware Twitter has had a history of abusing that data, but
| the initial reason for verification remains the same.
|
| I'm actually surprised more websites don't require
| verification. It's easy to do, and the benefits are very
| obvious. Most users aren't bothered by it either...
|
| Smaller ecommerce sites still keep the Guest Checkout
| flow available because they would rather not impede
| checkout for any reason - although that means they take
| on additional risk. Major ecommerce sites require
| accounts (think Amazon, Newegg, Etsy, Walmart, Zappos,
| Chewy) and some do require verification. At their scale,
| fraud and abuse become very difficult problems that
| require a lot of time/resources.
|
| OAuth/Social Login has removed some of the need to verify
| email addresses at the business level. This is because a
| trusted 3rd party Identity Provider has already done that
| for you, and most OIDC IDP's already provide an
| "email_verified" flag of sorts. Depending on your trust
| level (connecting to Google's IDP vs. random IDP), you
| can just use this data and assume it's been verified,
| removing that step for the customer.
| chongli wrote:
| _Dominos Pizza allows you to monitor in real time the
| status of your delivery on their website after checkout_
|
| Dominos doesn't even verify that you own an email address
| when you register one. I have received Dominos delivery
| updates sent to my email address for pizzas delivered to
| a person who doesn't even live in the same country as me.
| These updates contained a bunch of PII information about
| the customer including their exact home address depicted
| on a map inside the email.
|
| Web developers: verify that people own the email
| addresses or phone numbers that they register!
| marcosdumay wrote:
| Any site that requires a password will need an email for
| password resets.
| MichaelCollins wrote:
| If the site doesn't need email for anything besides that,
| then it doesn't need email for that either. Let the user
| set an email for account recovery if they want, but don't
| require it. If users who choose not to give an email
| forget their password, they can simply create another
| account.
|
| This is the way HN works. It's the way _most_ websites
| used to work, until maybe 15 years ago, give or take.
| Today almost all sites ask for verified email addresses,
| but this used to not be the case.
|
| Besides the commercial value of having user email
| addresses, I think it's mostly done for the webdev's ego:
|
| > Users _need_ to hear about my new update! (Because if I
| don 't spam their inbox, nobody will notice or care about
| the thing I just did.)
| ben0x539 wrote:
| I think the webdevs are right about this one. People lose
| or forget passwords all the time (in general not using
| password managers). Permanently losing access to an
| account sucks a lot. Tying account ownership to email
| primarily with passwords being more or less an optional
| convenience saving you the email roundtrip seems worth
| it.
| parminya wrote:
| > Permanently losing access to an account sucks a lot.
|
| But mostly that's all. Usually it's a minor
| inconvenience. Occasionally it sucks a bit. Rarely it
| sucks a lot. Almost never is anything of value lost. It
| can be wholly eliminated by good data practices e.g.
| backups. (No one backs up their Amazon account data. It
| isn't designed for it. Because the "webdevs" think of the
| data as their boss's - squarequoting "webdev" because the
| effective decision is the CEO's and the "webdev" is just
| taking some abstract, ill-thought-through decision and
| making the ramifications concrete.)
|
| On the other hand, it also sucks a lot when your
| gratuitously collected private information is taken to
| the darkweb. As countries become more accustomed to
| dealing with databreaches, they are beginning to consider
| legislating harsh compensation requirements and painful
| fines. Once that's happened, almost all of the private
| data that the user has in their account? Let the user
| keep it. We webdevs and our mortal enemies in
| business/sales/product will have to innovate new
| decentralised databases - where each node is a users'
| computer. And yeah, some things will be harder or not
| even possible (for the user). Other things will become
| possible that aren't at the moment (for the user). And at
| least you won't go bankrupt when a state level actor
| decides your database is valuable.
| EamonnMR wrote:
| Most people need to back up is a receipt for their
| transaction, and the main method people expect for
| receiving it is... email.
| Alupis wrote:
| There are some exceptions to this. Notably, Amazon is
| ruthless in enforcement of their "One Person, One
| Account" policy (worded not so eloquently in their
| official terms).
|
| If you lose access to your Amazon account and open a new
| account, there's a non-trivial chance they shut it down
| without explanation. If your account ever participated in
| the marketplace from a seller side, then this policy is
| even more ruthlessly enforced.
|
| Which means... email address verification is necessary
| for Amazon to at least guard against type-o's and other
| common form data-entry errors.
| echelon wrote:
| I worked for a big fintech.
|
| - Zero email validation at signup measurably reduces
| friction. [1]
|
| - Require email validation for bank deposits, once your
| customer is further onboarded and invested in the
| product.
|
| - Encourage 2FA and other measures as the customer grows.
|
| [1] (Much to the chagrin of all security-adjacent,
| marketing, account owning, risk, ATO prevention, etc.
| teams. I was directly in the path of these decisions, and
| it was interesting to see the various stakeholders argue
| their points. Growth funnel wears the pants.)
| EamonnMR wrote:
| Yeah you may not realize that a significant fraction of
| people don't remember passwords at all and need to reset
| on every login. If you don't allow self serve password
| resets you're creating a huge customer service burden.
| fabiospampinato wrote:
| Not true for end to end encrypted stuff, the server can't
| reset anything.
| renewiltord wrote:
| Users are trained to put in their email. Making them choose
| a username increases friction if the username is non-public
| (i.e. it's not instagram). Ideally, using SSO speeds the
| whole thing up, but if not, then it's better to just use
| email.
| jstarfish wrote:
| > Most sites that require an email don't need an email, and
| only ask for it so they can spam users with nonsense like
| product updates.
|
| Not the only reason. It _adds_ friction for people trying
| to create an army of sockpuppet accounts.
| gauravphoenix wrote:
| >spam users with nonsense like product updates
|
| IMHO, not all product updates are nonsense.
| MichaelCollins wrote:
| [x] - Send me emails about product updates.
|
| (Receiving these emails should be opt-in. But companies
| often find lame excuses to ignore this preference so I
| prefer to not hand over my email address at all.)
| ruined wrote:
| sending those messages is part of the same business case as
| reducing friction by not confirming the address :)
| KMag wrote:
| The lowest friction workflows make data collection/entry as
| lazy/delayed as possible and maximize optionality. Allow
| users to "save as default" as part of their normal workflows
| on your site, rather than demanding the information up-front
| at signup.
|
| The welcome/email verification email should have an expiring
| passwordless sign-in link (and maybe a way to set password if
| you decide to support passwords). If I use your site rarely
| enough, I don't even save your information into my password
| manager. Your password reset workflow is my normal sign-in
| workflow. Kudos to sites that don't force me to generate a
| one-time random password for this sign-in workflow. In
| practice, I think a lot of people accidentally use this as
| their login procedure on rarely visited sites.
|
| If account creation is part of the ordering workflow, make
| the most significant 6 (or more) digits of the order ID a
| secure message authentication code of the rest of the digits
| and delay verification of the email address. That allows you
| to delay email address verification and still securely
| correct email address typos (of recent orders) if the user
| records their order ID.
|
| If your site has made birthday mandatory but you haven't
| demanded a government ID for verification or run a credit
| check, I've lied to you about my birthday.
|
| If your site demanded a mailing address but you're not
| shipping anything to me, I've lied to you about my address.
|
| If you're demanding to over-collect information, and I'm
| polluting your data lake, that's on you.
|
| Side note: the McDonald's app is nice in not requiring (or
| apparently even allowing) passwords to log in. However,
| there's a problem with its state transition, where the user
| needs to exit from the dialog that sends the sign-in link
| before they go to their email and click on the sign-in link,
| otherwise the user gets dumped to the next step without
| having actually signed in.
| ev1 wrote:
| > Side note: the McDonald's app is nice in not requiring
| (or apparently even allowing) passwords to log in. However,
| there's a problem with its state transition, where the user
| needs to exit from the dialog that sends the sign-in link
| before they go to their email and click on the sign-in
| link, otherwise the user gets dumped to the next step
| without having actually signed in.
|
| The mcdonalds app loads several dozen data collection sdks,
| pihole practically had a meltdown when it launched
| Spooky23 wrote:
| Even an async validation would be better. I have <common
| name>@gmail.com, and get several newspapers and some other
| subscriptions for free.
|
| In one case, a person named Mary in Australia sends their
| loved one a gift card every year, and the retailer doesn't
| provide any information about Mary. In another case, a
| student missed out on their work study job and a opportunity
| for early class enrollment due to a bad email.
|
| It's sad as all of these customers don't even know that they
| have a problem.
| whateveracct wrote:
| Discussions of friction and login/signup always drive me
| crazy. Like I get the need to get people to sign up. But
| security is always an afterthought - it always loses to lower
| friction.
|
| And don't get me started when the PM starts lowering friction
| to the point where they are basically trying to trick the
| user.
| thefreeman wrote:
| And then what happens when the user tries to login with the
| password they just "created". They will get the same error
| message as before, but be extremely confused since they just
| "registered" with that password. Not to mention their browser
| may have prompted and stored the fake registration password,
| etc.
| darrinmn wrote:
| What do you mean login? I'm talking about the signup flow.
| The signin flow would be consistent with what is discussed in
| the article "invalid username or pw".
| thefreeman wrote:
| What do users usually do after registering an account? They
| try to login with it (assuming they aren't automatically
| logged in after registration which is what I would
| generally prefer / expect as a user).
|
| You are giving the user so many chances to just say "forget
| this" and move on to a different website. Especially if
| they are on mobile, registering for services is a huge pain
| in the butt.
|
| My basic point is you are severely impairing the UX to
| prevent what I think is an extremely minor and generally
| irrelevant piece of information leakage.
| gchamonlive wrote:
| The flow is
|
| 1. Sign up for an account 2. Enter the email 3. Receive a
| confirmation email 4. Create password 5. Sign in
|
| This is what op means. You just ingest step 2 without
| confirming the email is used or not. The actual account
| creation should occur only after email confirmation.
| thefreeman wrote:
| Gotcha. That does make more sense and basically signup
| and reset password are essentially the same process. If
| the user doesn't have an account previously at that point
| you collect the information needed to proceed. I
| personally would not want to break up my onboarding
| experience like this but I can see other people making
| the trade off.
| KMag wrote:
| If the GP is assuming that initial password setting is
| done via the verification link sent in the verification
| email, then the workflow they're proposing won't cause
| the confusion you describe. In other words, the "verify
| my email address" link is to a form that says "Create and
| verify password to confirm your email address."
|
| If you're assuming that initial password entry is done
| before email verification, then there's a possibility for
| confusion there.
|
| Honestly, the lowest friction workflows collect
| information lazily. Don't require setting a password (if
| at all... expiring login links in emails are a nice
| alternative) until the email is verified. Don't require a
| mailing address or credit card number at all, but have a
| "save for later" checkbox/button as part of the checkout
| workflow, etc.
| Guest9081239812 wrote:
| On my site it works this way...
|
| 1. Choose desired plan.
|
| 2. Enter username, password, checkbox for terms of
| service.
|
| 3. Get prompted to enter the 6 digit confirmation code
| that was emailed to you (if you were already registered,
| it says you have an account and links to the login and
| password reset pages if required).
|
| 4. Registration is complete and the user is automatically
| signed in.
|
| The username or email address isn't blocked until someone
| completes a registration with it.
| gondo wrote:
| The user should be automatically logged in after
| successful registration if the flow is implemented
| correctly.
| emodendroket wrote:
| You'd defer password setting if you were doing this I would
| think.
| rmbyrro wrote:
| Author talks about that in the article
| IshKebab wrote:
| I've used exactly one site ever that had this sign-up flow, and
| hundreds that had the stupid "invalid username or password"
| error.
| emodendroket wrote:
| That exact strategy is described in the second paragraph but
| the author argues (and I agree) that it is so arduous it will
| cause you to lose many users for questionable benefit.
| darrinmn wrote:
| Yes but the exact quote is confusing as he specifically
| mentions email addresses (in bold text). I know the author
| mentions usernames elsewhere in the article and I agree with
| the author this isn't applicable to websites that allow
| username signup since anyone can pick any random string...
| But for email address signup, as the exact quote mentions,
| there is no additional context switching since you already
| need to confirm the email address regardless.
| emodendroket wrote:
| Often you don't need to confirm the e-mail address to
| complete whatever workflow you're doing.
| darrinmn wrote:
| Sure, companies are free to make their own choices based
| on their business incentives. But if you can create an
| account and be logged in without verifying an email
| address, then arguably the email address wasn't needed in
| the first place and you should just allow any type of
| username string. If the goal of your website is for email
| address to be the username, the you should confirm the
| user actually owns the email address they claim first -
| since anyone could lie and put a random email they don't
| own.
| sbf501 wrote:
| 0.1% representing!
|
| I got some code to fix.
| layer8 wrote:
| This is bad in the case of online orders, where the order will
| usually go through anyway (vendors want to sell even when you
| don't confirm your email address, and don't care a lot about
| someone else getting the notification emails), because if by
| mistake you registered your email address as new although you
| already had an account with that address, the order won't get
| associated with your account. Or if it does automatically get
| associated with the account (or after confirmation), then
| that's bad as well if you really entered someone else's email
| address, because your order will then get associated with their
| account.
|
| This is the reason why attempting to sign up for an existing
| account generally fails right away, at least for online
| retailers.
| cryptoegorophy wrote:
| Woocommerce plug-in of Wordpress solved that issue. You can
| checkout as a guest with someone else's email, you won't see
| other orders from that email and if you do want to see them
| then you need to sign up for an account
| layer8 wrote:
| What if it wasn't someone else's email, but your own with
| an existing account? Can you re-associate your order with
| the existing account?
| darrinmn wrote:
| Not sure exactly what you mean? Are you referring to a
| purchase flow where you are buying something and also given
| the option to checkout as guest or signin/signup?
|
| I am only speaking to the typical signup flow that anyone can
| access signed out without putting in any information besides
| email/pw. If you are in a purchase flow where valid credit
| card info is already entered and is going to result in actual
| purchase $$, you've already excluded bots/hackers who would
| be trying to brute force account enumeration. It would be
| totally fine to confirm the existence of an account in a web
| form in this situation as it is not a flow that can be easily
| brute forced for free with little effort or info needed (like
| a credit card).
| lucideer wrote:
| > _the order will usually go through anyway_
|
| > _vendors want_
|
| If security is not a priority for the vendor, then yes.
| Otherwise, no, the order will not go through anyway.
|
| I'm very aware that in many many cases, the former is true in
| the real world, but that doesn't change the fact. This isn't
| a good justification for the op's dismissal of the practice.
| thomastjeffery wrote:
| Just reading the title, I expected OP to be talking about invalid
| passwords, _i.e._ when a password 's text can't be used because
| it's too short/long or has/doesn't have specific characters.
| That's a discussion I would be much more interested in; mostly
| because I'm sick of seeing long passwords be completely broken.
|
| A better title for their post would be "incorrect", not
| "invalid".
| andrelaszlo wrote:
| I don't get it. It's fine to leak/allow user enumeration on the
| login page because it's leaked elsewhere anyway? That's a pretty
| big assumption.
|
| One way to allow users to register using their email address
| without leaking any information is to just say "user created,
| please check your inbox to confirm your email address" or
| something like that. If the user already exists, swap the
| confirmation email for a warning email if they already have an
| account.
|
| Or am I missing something?
| [deleted]
| sgjohnson wrote:
| I'd say it's wrong to assume it's even a security measure. I'm
| fairly sure it goes like this
|
| if (db->query("SELECT * FROM `users` WHERE `email` =
| 'yesthisisdog@gmail.com' AND `password` = MD5('hunter2')") {
| login(username);
|
| } else { error('invalid username or password');
|
| }
|
| with nobody giving it a second thought.
| capableweb wrote:
| As someone who written countless of this authentication
| mechanisms or led teams that have, there has been 0 times the
| vague message have been by accident like you described and 100%
| on purpose to prevent information leakage. But that's just one
| (20+) anecdote(s).
| datalopers wrote:
| > MD5('****')
|
| That's cool HN censors passwords like this
| MHard wrote:
| Which in itself would be a bad security practice because that
| would mean that the passwords aren't individually salted.
| sgjohnson wrote:
| And they would be hashed using MD5!
|
| But on a serious note, it's possible to individually salt
| passwords, and still match username & password in one query.
| Sohcahtoa82 wrote:
| Everything about that query makes me cry.
| codingdave wrote:
| > Unfortunately this assumes that there's no other way for an
| attacker to discover whether a username/email address is
| registered for a service. This assumption is incorrect.
|
| Security is never perfect, it is always about making it annoying
| enough that people don't bother. So yes, there are other ways to
| see if someone has an account. But odds are the person attacking
| your site is not singling out one account to hack, they are
| trying bulk attacks with many accounts. So you avoid leaking info
| to not give the script any more ammo on what else to try. And
| hopefully the attacker will move on to some site that did give it
| more ammo.
| SamBam wrote:
| > it is always about making it annoying enough that people
| don't bother.
|
| > But odds are the person attacking your site is not singling
| out one account to hack, they are trying bulk attacks with many
| accounts.
|
| I feel like these two statements are at odds with each other. A
| regular user is going to get annoyed. An attacker using a
| script and multiple attempts is simply going to include the
| other way of verifying if an address is real in the script.
| kgwxd wrote:
| Maybe instead of saying the email address is already in use on
| the site, just let the "sign up" happen and tell them to check
| the email for a confirmation link, and in the confirmation
| email say "someone is attempting to sign up with this email
| that is already signed up, if this was you, use the Forgot
| Password link to reset the password for the existing account.
| If it was not, click here to report this incident."
| nibbleshifter wrote:
| If the signup or reset process enables user enumeration, we tend
| to ding you on that in audits the same way we ding you for
| enumeration via the login form.
|
| Captchas, timeouts and rate limits are all well and good, but
| given the attack tools (eg: SentryMBA, OpenBullet) used by the
| lowest common denominator solve for those (by using captcha API's
| and residential proxy networks)... Breaking user enumeration
| vectors becomes super useful.
| whirlwin wrote:
| Not a UX'er. But speaking of UX - it is inherently very annoying
| to sign in with username/password in general. At least in 2022.
| 2014 was perhaps different.
| mrmattyboy wrote:
| I'm not sure if someone has mentioned this already, but if
| someone has gone down the path to allow enumeration (username
| check during signup, which is immediately returned ton the user),
| I would say this is a strong argument where you could protect
| yourself against enumeration more easily..
|
| The amount of times a user will likely type their
| username/password incorrectly is going to be a lot higher than
| those who attempt to re-signup for an account. Therefore adding
| additional protection to the signup page (hard rate limiting,
| bot-protection) then aids to stop this username/email enumeration
| without the need to be as strict on a login page. This is also
| compiled with ip-based rate limiting/bot protection that can get
| very frustrating for users within a corporation that have single
| public IPs for all their users.
| throwaway09223 wrote:
| This is an extremely silly observation for HN, given that the
| usernames are published openly with every comment. My username is
| quite obviously "throwaway09223." There's no need to enumerate
| anything.
|
| Avoiding username enumeration is a reasonable goal for some sites
| in terms of hiding PII, but it is very obviously not a necessary
| security measure.
| crazygringo wrote:
| The article is about usernames as email addresses.
|
| Not about handles.
|
| HN doesn't reveal people's e-mail addresses, unless they choose
| to put it in their bio.
| kklisura wrote:
| > 99.9% of websites on the Internet will only let you create one
| account for each email address. So if you want to see if an email
| address has an account, try signing up for a new account with the
| same email address.
|
| So why not just send an email upon signup with existing email and
| just show success on signup? I'm guessing email would state that
| you already have an account there, maybe you need to reset
| password and email would provide instructions. Using this
| approach there would be no leakage of information and you can
| inform the user someone tried signing up with their email.
|
| Edit: This would work only if only email is required for signup,
| but it would not work with usernames.
| SamBam wrote:
| The article suggests this. But also says you're going to make
| sign-up a lot more lossy because the context-switching may make
| some people give up.
| nerf3000 wrote:
| Or just allow multiple accounts to use the same email (with an
| upper limit)
|
| Already people can chuck a + in the user part and register with
| the same email like joe+2@gmail.com so really there's not much
| point trying to maintain a 1:1 user to email ratio.
| mod wrote:
| That's what I've always done, with an upper limit of 1.
|
| More seriously, this just kicks the can a little bit.
|
| "Already people can chuck a + in the user part...so really
| there's not much point trying to maintain a 25:1 user to
| email ratio"
| justsomehnguy wrote:
| > Check submitted passwords against a dictionary of common
| passwords (123456, monkey, etc) and ban that traffic extra hard.
|
| > Give guidance to users about creating strong passwords
|
| Yeah, if I just want to talk about a propane with some folks I
| would eagerly wait to be lectured about IT security, scolded at
| my passwords of choice, go out of my way to appease site
| administrator's password policy...
| scarface74 wrote:
| Or with any modern password manager - including the one built
| into Apple devices - you could just click on "choose strong
| password" and have one generated for you and stored.
| justsomehnguy wrote:
| That works fine till you have the access to your password
| manager.
|
| If you ever find yourself without it... imagine your Apple
| device got broken/stolen. You would be fine wihtout an
| ability to talk on some forum, but what about critical
| banking, e-gov sites?
| scarface74 wrote:
| My passwords are synced between all of my devices - iPad,
| iPhone, and Mac.
|
| Even if I lost all of my devices, I could walk into a
| store, buy a new device and log in and all of my passwords
| with be in sync.
| boredemployee wrote:
| In 3rd world countries that would be a whole different
| story...
| scarface74 wrote:
| Doesn't Android also have a built in password manager
| that gets synced to Google servers?
| pixl97 wrote:
| The internet you want no longer exists.
|
| Stealing your account talking about propane sounds like a great
| way for me to inject spam/propaganda right in the middle of a
| group of trusted individuals. And this is exactly what we see
| countless times. Accounts with bad passwords get compromised,
| spam, then banned.
|
| You're using a shared resource, you need to use it responsibly.
| jbj wrote:
| > 99.9% of websites on the Internet will only let you create one
| account for each email address. So if you want to see if an email
| address has an account, try signing up for a new account with the
| same email address
|
| that may explain why my gmail keeps getting signed up for obscure
| cypto services :(
| tumetab1 wrote:
| This might need (2014) in the title
| TheMaskedCoder wrote:
| Agreed. OWASP now advises developers on how to avoid account
| enumeration, so this take no longer makes sense.
| dfxm12 wrote:
| _So what we 've done by promoting "Invalid username or password"
| is made our login form UX much, much worse, without increasing
| the security of our product._
|
| Much, much worse? Not at all. It doesn't matter if you've
| forgotten your user name, email address or password; if you've
| forgotten your credentials, you reset your password, not keep
| guessing until you give up. The password reset will also clue you
| in as to if you've got the right email address.
| JoeAltmaier wrote:
| True but aren't username/password passe? Username should be
| 'account details' like mother's maiden name or zipcode, not a
| security feature.
|
| And short passwords you change a lot - what a weak system!
|
| How about provide a cryptographic key and that's it. It's right
| or it's wrong.
|
| Or heck, if it's not recognized then just create a new empty
| account.
___________________________________________________________________
(page generated 2022-11-23 23:01 UTC)