[HN Gopher] The "email is authentication" pattern
___________________________________________________________________
The "email is authentication" pattern
Author : Brajeshwar
Score : 289 points
Date : 2024-09-07 17:48 UTC (1 days ago)
(HTM) web link (rubenerd.com)
(TXT) w3m dump (rubenerd.com)
| threatofrain wrote:
| People have already been building auth flows that take this
| password amnesia into consideration. Look at Anthropic. It's just
| one way of doing auth and I personally hate it.
| voiper1 wrote:
| I use a password manager. I don't like flipping back to my
| email, I already have a secure password.
| cpach wrote:
| Same here! But for most apps we are probably in the 0,1% or
| so.
| ydnaclementine wrote:
| The most secure password is no password
| hansvm wrote:
| Totally agreed. The account though, that's another
| question. Would you mind sharing the username of your
| favorite passwordless account?
| rembicilious wrote:
| Personally, I don't care to share the username to any
| account, password protected or not. On a related note I
| think it is terrible security to have display name be the
| same as user login name.
| doctorpangloss wrote:
| Anthropic and others do this to inconvenience account sharing.
| It's not really about auth, it's about licenses...
| archerx wrote:
| There are much smarter ways of doing this.
| tptacek wrote:
| Email accounts are the highest common denominator in online
| authentication. Phones are competitive, but people lose phones.
| Phone numbers are more common and durable, but the security of
| phone numbers is leagues below that of a flagship provider email
| account. It makes sense that so many authentication flows work
| this way.
|
| When designing a "fantasy football" alternate authentication
| system for the Internet, start with account recovery: what
| happens when a user loses your fancy authenticator? If the answer
| is "they just don't get access anymore" or "a panel of their
| peers attests to them", your fantasy authentication system also
| needs a fantasy species of sentient beings to serve as users,
| because it won't work for humans.
| hgomersall wrote:
| It's an interesting design problem to have panel of peers
| attest an individual's identity. It could be made fairly
| seamless if there was a common system in which a suitably
| distributed authentication secret could be recombined under
| instruction from the relevant party. Can it be made to work for
| normal humans? I daresay we have the ingenuity to design
| something...
| unilynx wrote:
| except that those instructions will be handed out by phishers
| jlund-molfese wrote:
| Apple's Recovery Contacts are a similar idea. The main
| difference is that just one can help you recover your
| account, but it doesn't seem too hard from a UX perspective
| to make 3/5 recovery contacts required to unlock an account.
|
| https://support.apple.com/en-us/102641
| efitz wrote:
| We could also leverage trusted third parties for this
| purpose, for example, banks or DMV or Walmart.
|
| However, there needs to be a fiduciary interest by the third-
| party (eg liability for identity theft, etc) in order to
| incentivize them to avoid fraud. It is not clear that there
| would be enough profit involved to offset the liability.
| kfrzcode wrote:
| The Decentralized Recovery (DeRec) Alliance has recently
| launched to solve this very problem. Dr. Leemon Baird gave a
| talk last year on how this works at a higher level [0]. The
| alliance is comprised of members from the Algorand, Hedera,
| Ripple crypto communities but the application of proper DeRec
| would be certainly applicable anywhere you have any type of
| secret; in fact I believe you can be a DeRec 'helper' right
| now. There's a robust primer on the protocol published as
| well [1], here's a pull-quote:
|
| > Decentralized recovery is a method of safeguarding a user's
| secret by distributing shares of that secret among multiple
| helpers, who store their individual share on their local
| device in order to help the user recover that secret in
| future. The shares are constructed under a threshold secret-
| sharing scheme (e.g. Shamir's secret sharing scheme), with a
| chosen threshold (defaults to half) -- at least three helpers
| must be present in order to use the protocol. Should the user
| lose access to their device, they can recover their secret
| data by retrieving the previously-distributed shares from at
| least half of their helpers. For successful recovery, the
| user only needs to recall the identities of half of their
| helpers and authenticate with them in-person.
|
| [0]: https://www.youtube.com/watch?v=AcF4abPoveM
|
| [1]: https://github.com/derecalliance/protocol/blob/main/prot
| ocol...
| simonw wrote:
| Some day someone is going to produce a fantastic heist
| movie about breaking this kind of scheme - five different
| characters, each of which need to be scammed in different
| ways to obtain their piece of a shared secret.
|
| Sadly it's quite possible this will be a dramatized version
| of a real-world event. We've already seen quite a few
| messed up crimes to steal keys to steal crypto. Secret
| sharing just means you need to kidnap a few extra people.
| kfrzcode wrote:
| But in fact, in order to kidnap these people you'd also
| need to know these people, and know they are assigned to
| be part of the derec network. With DeRec all the helpers
| don't need to know about each other at all. And you may
| not know how many helpers a given helper has behind them.
| It's actually much much more difficult to do the heist-
| and-interrogate-with-a-pipe-wrench approach if you don't
| know who to beat up, nor how many of them need to
| authenticate.
|
| Edit: OT but while I have a glimpse of your attention,
| kudos in order!! I love datasette and basically
| everything you write is highly useful to me!
| hgomersall wrote:
| I came up with a similar general approach about 10 years
| ago, but lacked the time or inclination (and probably
| knowledge, frankly) so I'm very pleased this is being
| pursued.
| kccqzy wrote:
| Of course it works. I was aware of such mechanisms appearing
| in the Chinese social media app WeChat years ago. In fact I
| would say it's a great fit for any kind of social media app
| that involves interacting with peers.
|
| However the utility is probably nil if there're no social
| features to begin with.
| crooked-v wrote:
| Unfortunately, "they just don't get access anymore" is the
| usual pattern with major email providers like Google, as many
| people who have had a phone lost or stolen and then been locked
| out of their accounts forever can attest to.
| candiddevmike wrote:
| Government provided digital IDs would solve a lot of this. Yes,
| they may have their own problems, but outsourcing the action of
| identifying individuals to the government seems valuable and
| less prone to "lock outs" like Google and friends.
| jpalomaki wrote:
| Yes. I would very much like to tie certain accounts to my
| government issued digital identity and allow that as the only
| recovery method.
| JumpCrisscross wrote:
| > _Government provided digital IDs would solve a lot of this_
|
| A lot of what? It seems like the worst of all worlds, given
| that ID would not only unlock some _highly_ sensitive things,
| but also be difficult to change and tremendously revealing.
| iknowstuff wrote:
| Nah the government could just give a website a unique id
| per real user per website, without revealing who the user
| is. Merely verifying that they are the same person as last
| time.
| quectophoton wrote:
| It certainly is an alternative we can at least think about.
|
| On one hand, the certs you'd use to login to websites
| wouldn't even need to include any personal info at all, just
| a valid signature from a CA that the website knows how to
| verify. And the certificate wouldn't need to be the same for
| every website, it could be one you generate for a specific
| website.
|
| On the other hand, a lot of thought would need to be put into
| how expiration/renewal and revocation would play into this.
|
| Of course there should be an evaluation of the ways this
| could go wrong if someone from the gov misuses this CA, and
| how that compares to someone from your current email provider
| misusing their permissions.
|
| But if nothing else, something I really want is to just be
| able to have an email address like
| `random_id@my_country.my_country_tld`, to at least have an
| email address where I don't have to worry about being locked
| out, so that I can give freely to ISP, bank, grocery delivery
| websites, other local companies, etc. Most of this stuff I
| wouldn't even mind receiving as postal mail anyway. And if
| shit hits the fan, I can recover access to this email account
| by walking to an office and identifying myself.
| layer8 wrote:
| Having only a single such address also means you can be
| blacklisted forever, in addition to being tracked across
| services.
| quectophoton wrote:
| What I had in mind was more like randomly generated
| addresses as needed, all of them linked to your (one)
| mailbox. Like Apple's "Hide My Email", but without
| needing a "main"/"canonical" email address because it
| would be unnecessary anyway (because you would be logging
| in to your mailbox with your own certificate).
|
| But even if that single-address limitation were the case,
| the kind of places I would give it to already require
| knowing my national ID number anyway, so the two
| particular things you mention are already the status quo.
|
| In other words, stuff that is already tied to having a
| verifiable citizenship.
| ristos wrote:
| It exists for US citizens at least: login.gov
| (https://developers.login.gov/oidc/getting-started/)
|
| It has it's pros and cons, maybe more pros if you factor in
| that the biggest issue isn't authentication really, it's the
| fact that all of these private companies accrue everyone's
| sensitive info, which can be abused by any actor, private or
| public. If data were kept on the client side, and synced to
| other machines through P2P like WebRTC, then maybe this
| wouldn't be such a big deal.
| joncfoo wrote:
| Unfortunately login.gov is only available for use by
| companies doing business with the US government.
| capitainenemo wrote:
| Also login.gov isn't a government issued digital ID. It's
| just a centralised authentication platform for government
| use, much like using google or apple for authentication.
|
| It supports the usual options for multifactor (TOTP,
| text, yubikey/other hardware auth/PIV cards) but for most
| users it probably ends up being SMS. At best TOTP.
| DANmode wrote:
| Humans understanding the basic concept of public/private
| keys,
|
| wanting a Yubikey or similar,
|
| and/or being able to use basic tools to make a key,
|
| would also help.
|
| But I'll take the government-led method as a Plan B, if it
| works.
| aucisson_masque wrote:
| > Government provided digital IDs
|
| Oh man, that sounds like a terrible idea privacy wise. Every
| website would make use of it to track it's user.
| pennomi wrote:
| I think it makes sense as the master recovery account. Then
| you use a secondary account for everything else.
| eaglemfo wrote:
| The german gov ids actually have a way to issue
| pseudonymous tokens where websites can only see that you
| are the same person as last time. You can't make 2 accounts
| on the same site if sich things are unwanted. You can't
| link accounts across providers.
|
| How it works under the hood? No specific idea. I wonder if
| its sound.
| rangestransform wrote:
| The problem is the government can then definitively
| associate all your accounts with your real identity
| noAnswer wrote:
| How does the government know which token a ID card
| generated? The ID card itself generates (for each service
| a different one) and encrypts it. Not even the card
| reader can read it. It is a encrypted channel between the
| card and the ID-server for the site/service. The
| pseudonym function does not identify a person but a card.
| jack_pp wrote:
| If it identifies the card and the govt can identify you
| by your card then isn't it by definition identifying the
| person?
| noAnswer wrote:
| The government doesn't know which card a token from a
| "pseudonym function" belongs to. The government can
| identify a person when the ID function was used, of
| course.
|
| Again, it is a random token the card generates internally
| for each service. It is non transferable! If you get a
| new ID card, you can't use it login to whatever you used
| your old card for. (You would need something else... say
| an email :-) to tie the knot back to the old identity or
| whatever.) Which makes this function, the pseudonym
| function, very bad for random accounts (Edit: meaning
| longer lasting online identities like forums or
| whatever). I guess eaglemfo didn't knew.
|
| It's more for like "yes, yes, I'm an adult, now give me
| this pr0n movie which I pay for with my anonym prepaid
| card" kind of deals.
| taneq wrote:
| I read this as tongue-in-cheek at first (since most web
| sites do their darnedest to track their users, and having a
| log-on kind of requires this anyway).
|
| A centralized authentication system like this wouldn't need
| to be a single consistent UUID per person which was then
| passed around. Presumably you'd have a central login to
| authenticate you to the system, and then the system could
| create separate 'id' tokens per web site or whatever that
| the user logs in to.
| j45 wrote:
| I'm not so sure how many ppl would leave a key to their
| house, or a pin to their bank account with the government. Or
| a bank.
|
| Identity is relatively solved, there are just lots of
| sacrifices made in security in the name of convenience.
|
| Fingerprints as consent to login, Facial recognition as
| consent to login... seems more like a username, than a
| password, or a username+password.
| terribleperson wrote:
| I think I've said it before, but I want USPS-provided email.
| To set one up you'd go to a post office, verify your identity
| in some way, and set up an email. If you forget your password
| and want to recover it, you'd have to go back into a post
| office and verify your identity again.
| weikju wrote:
| Now you lock out the rest of the world until they can
| implement this and federate identities between countries.
| scubbo wrote:
| That's not a problem. Many systems and services have
| launched geolocked to certain countries before later
| expanding (Google Voice, for one).
| hnbad wrote:
| Germany has PostIdent: you are issued a code, take it to
| the closest post office, hand them the code (originally
| this involved printouts) and your ID card and they scan
| your ID card and enter it into their system where the
| issuer of the code can then request that info to verify
| your identity.
|
| This has largely been replaced by videochat for ID card
| verification where some underpaid person walks you through
| holding your ID card in front of your smartphone cameras to
| verify that it's real, not CG, not tampered with and
| matches your claimed identity.
|
| The critical aspect here is that you don't have to hand
| your ID card (or a picture of it) to the company that wants
| to know your identity. The post office or the videochat
| provider serves as a trusted source of truth.
| elros wrote:
| Initially when I moved to Germany I thought it was a bit
| of a hassle to have to go to the post office for
| PostIdent; now I actually miss the elegance and privacy
| of that system in other countries.
| noAnswer wrote:
| Or you hold our ID card to your phone and do it on the
| spot.
|
| https://www.deutschepost.de/en/p/postident/geschaeftskund
| en/...
| kolmogorov wrote:
| https://en.wikipedia.org/wiki/De-Mail also was an attempt
| ww520 wrote:
| That takes mail spamming to the next level. (I'll show
| myself out...)
| quectophoton wrote:
| Yes!
|
| Stuff like national ID, banks, ISP, job search websites,
| doctor appointments, etc, require[1] having an email
| address, and it feels wrong using gmail and similar
| providers for these use cases that are already tied to you
| having a physical presence in that location anyway.
|
| Could be provided by any local company, really, but postal
| services are not going to disappear anytime soon and they
| already have a second way of getting in contact with you if
| there's any issue (registered mail[2]).
|
| Debit cards are already delivered through postal mail
| anyway, and there's not many things that are more sensitive
| than that.
|
| [1]: Well, maybe doctor appointments don't _require_ and
| only _strongly encourage_ , but that doesn't affect the
| point too much.
|
| [2]: https://en.wikipedia.org/wiki/Registered_mail
| alberth wrote:
| To get a RealID drivers license in the US, which will be
| required to board a plane soon, requires all of the above
| and more.
|
| It's a government in-person KYC.
| FireBeyond wrote:
| The irony with that is that if someone undocumented
| wanted to leave the country, this requirement could
| potentially hinder that.
|
| I also don't really want to have to carry my green card
| around everywhere. Just one more thing that can be lost.
| alberth wrote:
| How would it?
|
| To travel internationally, a passport is required (not
| drivers licenses).
| FireBeyond wrote:
| I might have been being more simplistic than I needed to
| be, because there are other travel methods, but I was
| more meaning, "Not everyone lives next door to an
| international hub" (so might need a connecting domestic
| flight).
| tbrownaw wrote:
| > _which will be required to board a plane soon_
|
| Assuming that _this_ time the deadline doesn 't get
| pushed back at the last minute again like has kept
| happening so far.
| chrisweekly wrote:
| Passport will also work
| eesmith wrote:
| Not 100% required, even for adults.
|
| Those without acceptable identification may complete an
| identity verification process and face additional
| screening. https://www.tsa.gov/travel/security-
| screening/identification
| bombcar wrote:
| Everyone should experience this at least once - it's eye
| opening.
|
| I did it involuntarily because I forgot my wallet once,
| and decided "well, I'll either get through and in my way,
| or I'm too late to drive home anyway and will miss" - and
| it worked fine.
|
| Even crossed back into the USA without my passport a few
| times. Just additional screening and bitching is all (at
| least if you're a US citizen; membership in the Empire
| has its perks!).
| loeg wrote:
| RealID requirement for domestic flights (still) isn't
| happening, just like it hasn't happened since it was
| first announced for requirement in 2008.
| kmoser wrote:
| No, thank you. I don't want anybody with a fake ID of me to
| be able to take control of my email. I want to use my
| password, I want it strongly encrypted at rest, and I want
| to be able to reset it remotely any time of day, without
| waiting for the USPS office to open.
| terribleperson wrote:
| Is a fake ID going to fly at the post office, where they
| can scan them? Also, I was imagining they'd want more
| than just an ID.
|
| edit: Also also, they have to go into a physical post
| office and be observed trying to steal your account.
| Given how it's quite possible to steal accounts via
| social engineering, this seems like an improvement in
| security, not a reduction.
| kmoser wrote:
| I don't want a government entity, or really any entity
| I'm not paying directly for their services, to be the
| gatekeeper between me and my accounts.
|
| The social engineering attack surface of my account
| currently consists of a handful of support contacts at my
| ISP, who have been trained to deal with computer
| security. If you allow any USPS employee to access your
| account, you've suddenly increased the potential attack
| surface by several orders of magnitude.
| thbb123 wrote:
| The french postal services does that and includes a digital
| wallet and cloud repository.for instance, my paycheck
| certificates are delivered on this wallet.
|
| Besides, the french administration is providing its own
| global scheme for online authentication.
|
| Right now it works for all public services, but it is also
| open to all willing businesses.
|
| It makes it also very easy to control tightly what kind of
| information is distributed to various services and
| businesses.
| aborsy wrote:
| What are the names of these services, to see how they
| work, their recovery process and abuse prevention?
| palsecam wrote:
| https://www.laPoste.fr/digiposte (digital safe) &
| https://laPoste.net/accueil (e-mail); offered by the
| postal services.
|
| https://FranceConnect.gouv.fr/ is the online auth
| provided by the administration.
| imoverclocked wrote:
| I'm not sure I trust USPS to get all of the ins/outs of
| email spam/security/ux right. Google has spent a lot of
| resources to get Gmail to where it is today, starting from
| scratch (or OSS) seems like a big ask.
|
| Maybe we just ask for an open authentication system
| instead? Leave the email part to someone else... and maybe
| the open authentication can plug a crypto app/email/phone
| backend for recovery once it is setup. Heck, given that's
| it's the USPS, they will probably offer a snail-mail
| recovery option (for better or worse.)
| chii wrote:
| I don't want a semi-gov't authorized service like this.
| Because its existence means services would want to mandate
| it (even if they don't truly need it), and force users to
| identify themselves directly - may be even across services
| (by matching their email address, which now must be unique
| as it is identity-linked).
|
| I personally sign up to all online services with a
| different email each. I would like to be sure that my
| identity is hidden behind an alias for all services, so
| that they cannot be linked together. And if i want multiple
| accounts (for better or worse), i should be able to achieve
| that end.
| throwaway290 wrote:
| Australia is working on zero knowledge proof. The end
| service only knows that you are legit/of age/etc (only
| what it needs) because gov service confirmed it, but does
| not know who you are
| ozr wrote:
| I haven't heard a compelling argument that anything _needs_
| to be fixed with email-based auth patterns. It is imperfect
| but not bad, and every proposed alternative seems to be
| worse.
|
| The article seems to lean into security and usability
| concerns.
|
| On the security front: the weak-point is still the human. If
| you hand over your credentials to someone nefarious, well..
| you handed over your credentials to someone nefarious.
|
| Usability isn't convincing me either. One of the great things
| about email is that it really is the lowest-common
| denominator, as another commenter mentioned above. (Almost)
| everyone, from kids to the most tech-inept luddite have some
| sort of email.
| JonChesterfield wrote:
| One flaw is I'm pretty sure a lot gmail account is lost
| forever. Contacting Google to retrieve access would not go
| well. Related is that if you try to self host email your
| messages are unlikely to reach anyone.
| jerf wrote:
| Self-hosting _outbound_ email is hard.
|
| Self-hosting _inbound_ email is trivial. Anybody will
| _send_ email to any random domain, they 're just not
| willing to accept it from random sources.
|
| And the latter is what is relevant for password recovery.
|
| I self-host inbound but use established servers for
| outbound through my ISP and have had no trouble with that
| setup for a while. Forwarding to people through my domain
| has gotten a bit more challenging lately but I've got it
| working well enough to satisfy gmail so far. (The
| advantage with forwarding is you only have to convince
| one server to accept it, not everyone in the world, and
| there's some crypto stuff involved now that involves
| trusting some keys, not just a domain or IP, which also
| helps a lot.)
| JonChesterfield wrote:
| That seems a great compromise. I hadn't registered the
| distinction in direction. Even without organising the
| forwarding part there are plenty of organisations that
| email me password resets that I don't need to send email
| out to.
| JadeNB wrote:
| > Self-hosting inbound email is trivial. Anybody will
| send email to any random domain, they're just not willing
| to accept it from random sources.
|
| In terms of authentication, this is not entirely true.
| It's less common these days, but I used to have a lot of
| trouble with sites rejecting my attempts to create
| accounts with e-mail addresses from my disposable-e-mail-
| generator of choice.
| FireBeyond wrote:
| > from my disposable-e-mail-generator
|
| Well, I suspect those are more specifically blacklisted.
| elric wrote:
| Just yesterday I tried to register for a service using
| one of my own domain names with self hosted email. The
| confirmation mail arrived, but as soon as I clickes the
| link I was told that my email address wasn't allowed.....
|
| Not sure what kind of crap some folks are smoking,
| really.
| witrak wrote:
| >Self-hosting inbound email is trivial. Anybody will send
| email to any random domain, they're just not willing to
| accept it from random sources.
|
| That is simply not true. I have self-hosted email service
| and starting about 1.5 yr ago some big email services
| don't deliver emails to my server anymore. And there are
| many similar cases reported...
|
| So one can say that _even if_ an independent email
| service is willing to accept email traffic from any
| sender it does not guarantee that customers of _all other
| services_ can have delivered their emails to addresses at
| the service.
| ozr wrote:
| I'm not saying there aren't flaws, I'm saying none of
| them happen at a rate significant enough to be worth
| switching to another system (with an entirely new set of
| flaws).
| eaglemfo wrote:
| Wasn't there a recent sidechannel attack on Infineon
| cryptography chips? The EU passports likely use the Infineon
| chips.
| dilyevsky wrote:
| ID.me kinda already does this. They integrate with IRS, SSA
| and bunch of local government stuff
| easton wrote:
| Login.gov is the US Government's homegrown solution, which
| also does it. It's not one account <-> one citizen though,
| which you'd probably want in a real government id system.
| 9cb14c1ec0 wrote:
| How about a bank-provided digital id that you get when
| opening an account by walking into a physical bank location
| and providing your photo ID? It would tick the "less prone to
| lock out" problem without placing even more power in
| government hands.
| scrollaway wrote:
| We have this in Belgium and it's really not that good. It
| created a pattern of companies relying on people having an
| account at certain banks; which when you're either
| immigrant or unbanked is unlikely and shuts you out of
| certain businesses.
|
| It's been phased out for the government provided login
| system which is much better but not exactly simple for
| laypeople to set up. On top of this, integrating with it
| requires an extensive certification process, it's not just
| an open API.
| jks wrote:
| Banking credentials are used a lot in Finland to sign
| into other services. This means you get phishing emails
| saying "your medical test results are available" or
| "you're getting a tax return" where the actual goal is to
| get into your bank account.
| dalke wrote:
| Bank provided causes problems with people who don't have
| bank accounts. Here in Sweden most people use bank-provided
| electronic ID called "BankID".
|
| Quoting "Foreign citizens in Sweden blocked from BankID
| after several banks roll out new rules"
| https://www.thelocal.se/20220117/foreign-citizens-in-
| sweden-...
|
| > "We have been working systematically for six months to
| get residence permit cards, then a personal number, then a
| Skatteverket national ID card, and finally bank accounts.
| To our shock, we were just told by ICA Banken that the
| Skatteverket National ID - the only one available to non-
| citizens - is not a valid source of identification for
| BankID."
|
| BankID causes problems because it isn't designed for the
| interests of the whole population. For example, it requires
| proprietary software which only runs on Microsoft Windows,
| macOS, iOS, or Android, with hardware verification and
| Google services.
|
| This makes it unacceptable to free software advocates, and
| to privacy advocates, and to national data sovereignty
| advocates .. the total population of which is so small as
| to not affect the banks' commercial interests.
|
| One thing I learned recently is how the US can, with its
| control over the SWIFT banking network, tell banks in other
| countries to shut down the account for a local citizen who
| the US has designated a terrorist. At least that's what I
| gather from the news I read after two leaders of the
| biggest neo-nazi group here in Sweden were designated as
| terrorists by the US.
|
| If the goal is to keep power out of government hands, don't
| look to highly-regulated banks which are subject to the
| whims of multiple governments.
| SAI_Peregrinus wrote:
| My wife works in a city clerk's office. They provide (among
| other things) vital records services for the city. Like
| getting birth certificates.
|
| To get a birth certificate, you must provide government photo
| ID _with a name matching that of one of the names on the
| certificate you 're trying to get_. So you can get your own,
| or your child's, but not some random other person's.
|
| Lots of people were born before RealID driver's licenses.
| Some of them went by names other than the names on their
| birth certificates, and thus are unable to get new copies of
| their birth certificates using the government-issued photo ID
| they currently have. E.g. I've got a grandfather who went by
| Sam his entire life but was apparently named Harold. His
| driver's license had Sam as his first name. If he had lost
| his birth certificate, he would not have been able to obtain
| a new copy legally using that driver's license! This still
| happens to people. Also sometimes house fires or similar
| disasters happen, and people lack the ID needed to get new
| government-issued ID.
| tsimionescu wrote:
| These things can be solved too, but in a more complicated
| process. Typically some lawyers and a judge need to get
| involved, get some people to testify that you are this same
| person, and you will be issued new ID.
| WhyNotHugo wrote:
| How did he get a driver's licence with the name "Sam"?
| Don't you need some form of judicial process to change your
| name on this kind of thing?
| cyberax wrote:
| Clear in the US can do that: https://www.clearme.com/for-
| your-business
|
| It's not exactly a government service, but Clear is trusted
| by the government enough to allow their customers to bypass
| the airport screenings.
| lotsofpulp wrote:
| Screw Clear and screw the US government for allowing more
| privatization of public infrastructure.
| JadeNB wrote:
| > Government provided digital IDs would solve a lot of this.
| Yes, they may have their own problems, but outsourcing the
| action of identifying individuals to the government seems
| valuable and less prone to "lock outs" like Google and
| friends.
|
| Sadly, the US government goes the other way and contracts out
| verification (to government websites!) to an invasive private
| company.
| jks wrote:
| Estonia has this: <https://e-estonia.com/solutions/estonian-
| e-identity/id-card/>
|
| Finland tried to copy it, but the Finnish card (while based
| on the same technology) is used very little. Finnish banks
| already had their own OTP solutions, which they started
| offering for authentication on other web sites, so no-one
| wanted an extra authenticator on top of that. This of course
| means that you get phishing emails pretending to be from all
| sorts of government services, where the goal is to get your
| banking credentials and take your money.
|
| Since then, mobile phone operators added their own
| authentication system based on credentials residing on your
| SIM card <https://mobiilivarmenne.fi/en/>. You prove your
| identity when getting a mobile phone contract and can then
| use that to log into many sites.
| rocqua wrote:
| identification is different from authentication. But
| authentication at least as a backstop, can generally be
| decently outsourced to government.
|
| Not so much in the US though. They have no national registry
| of what citizens actually exist.
| alkonaut wrote:
| It does solve a lot of this. Some have gov't issued IDs,
| others have a hybrid public/private system where banks issue
| the ids. But yes, a de facto standard electronic ID is almost
| unthinkable to not have. How else do you interact with
| authorities or healthcare? I used e-ID since long before
| smartphones, I can barely picture what it would be like to
| log in to handle taxes, benefits medicine recipes or doctors
| appointments if it worked any other way.
| KronisLV wrote:
| > Government provided digital IDs would solve a lot of this.
|
| Over here in EU, we have something like it - you get an ID
| card that has two PIN codes that you can use with a card
| reader and some software to digitally sign documents and
| such: https://www.eparaksts.lv/en/ (of course, there's also a
| mobile version)
|
| In addition, there now are services where you can log in to
| your bank account, confirm payments, or just log in to your
| government portal account with a two factor app, the account
| on which is based on your identity: https://www.smart-id.com/
|
| So if I make a payment online with my card, I'll have to
| authenticate through either a code calculator (physical piece
| of hardware) or the phone app with codes that I've chosen, to
| confirm it. Same for logging into various sites, for example,
| for paying my utilities.
|
| Works pretty well and if I lose my ID card, then I can get a
| new one, issue new certificates for the apps and continue
| where I left off (with the old ones being revoked). I might
| need a backup phone too, though, since not being able to
| confirm my payments if my phone breaks is pretty stupid
| (though I guess Revolut/PayPal/whatever still work as
| expected, unless I only have my OTP codes for those on said
| phone).
| nfw2 wrote:
| Can you expand what you mean when you say the security of phone
| numbers is leagues below email? If someone can gain access to
| someone's phone, it seems like they would gain access to their
| email as well.
| tptacek wrote:
| Phone _number_ , not phone.
| nfw2 wrote:
| How does an attacker gain access to a phone number without
| having the phone? Like physically stealing the sim card or
| something else?
| fragmede wrote:
| bribe, coerce, and social engineer a phone company
| employee into transferring the victims phone number to
| you, or a technical attack to get the system to send the
| sms messages to a device you control, without ever
| touching the victim.
| Zanfa wrote:
| The attacker just needs to convince/compromise a single
| carrier employee to get a new SIM for your number.
| 57FkMytWjyFu wrote:
| Sim swap via pretending to be a clueless customer who
| lost their physical phone, banking on lax checks at
| customer service.
| oretoz wrote:
| As others have mentioned, SIM Swap attacks are very
| common where the attacker impersonates the victim and
| convinces the mobile operator to transfer the victim's
| phone number (known as MSISDN in telecom parlance) to the
| attacker's SIM. If you Google SIM Swap, you will find
| many instances of it.
|
| From that moment onwards, all the 2nd factor SMS OTP go
| to the attacker.
|
| There are APIs that are provided by mobile operators via
| aggregators such as Telesign, Prove, Vonage, Twilio etc.
| that can be used to check if a SIM Swap has happened
| recently on that phone number. That API is used by
| fintech companies and others e.g. when they want to check
| if a fund transfer is to be allowed or flagged up.
| efitz wrote:
| Mobile phones identify themselves to the mobile network
| through a number called the IMEI. IMEI cloning is not
| particularly difficult nor does it require exotic equipment.
| This means that it is relatively easy for an attacker to be
| able to spoof your phone to a mobile network, for example, to
| receive SMS messages with one time passwords.
|
| Cloning your IMEI has nothing to do with the data that is on
| your phone, so if someone clones your IMEI it does not mean
| that they have access to any of the apps or data that is on
| your phone.
| nfw2 wrote:
| Thanks for the clarification!
| kjellsbells wrote:
| IMEI or IMSI? I think it is the subscriber identity that is
| on the SIM that needs to be cloned, not the hardware
| identifier of the device (ie its the IMSI that matters, not
| the IMEI).
|
| SIMs and SIM burners can be purchased trivially on the open
| market, and cloned without too much difficulty. Although, a
| social engineering attack on the employee at the cellphone
| store is a superior method since it automatically gives you
| a "known good" SIM with the operator's keys, etc.
| lxgr wrote:
| Neither the IMEI nor the IMSI is used for authentication.
| The IMSI is slightly closer to the truth (while still
| missing by a mile), but without the per-IMSI
| authentication key (which is never transmitted over the
| air interface, whether in plaintext or encrypted), it's
| useless as well.
| lxgr wrote:
| That's completely wrong. The IMEI doesn't play any role in
| GSM/UMTS/LTE/5G authentication (if it's recorded, that's
| usually for debugging or tracking purposes).
|
| While there are weaknesses, every mobile phone standard
| since GSM (not sure about the equivalent for the CDMA
| world) uses cryptographic authentication, many of which
| have been subsequently broken, but it's just not true that
| simple knowledge of a bearer token, transmitted over the
| air interface, grants you sufficient access to receive
| somebody else's SMS.
|
| Most practical attacks actually focus on either attacking
| the core network via SS7 (and making it deliver SMS to the
| attacker instead of the actual recipient) or on breaking
| the air interface encryption, which requires you to be
| physically close to the legitimate recipient while they
| receive the SMS over the air.
|
| You can change your IMEI to mine right now, and absolutely
| nothing would happen (other than maybe our phone operator
| getting mildly confused, if we share one and they're
| tracking IMEIs for whatever reason).
| jpalomaki wrote:
| Phone companied have customer support. This is a weak point,
| because attacker can use social engineering to gain access to
| your number.
| j45 wrote:
| SMS codes for anything are not secure. Convenience over
| security, maybe.
|
| SMS are as secure as a letter compared to a postcard.
| paradox460 wrote:
| And they're rather irritating to boot. TOTP authentication
| in something like keypass or 1password is very low
| friction, working automatically in ideal circumstances. Sms
| based ones are kludgy
| gerdesj wrote:
| Auth apps are crap - each one pretends to be unique and
| authoritative.
|
| TOTP secrets are a string, not just a QR code that can only be
| seen once and never again - the QR code merely encodes that
| string! That string can be used in multiple places to generate
| codes. KeepassXC can do it and that can be shared. I've seen
| loads of organisations and sites with an elderly mobile phone
| that has the TOTP auth app on it. Normally MS Authenticator.
|
| To add insult to injury, MS Auth can only have one account per
| email address (id@realm/whatever you want to call it).
|
| PrivacyIdea can do email based TOTP with a PIN. That works well
| but does involve a two stage login with an email delivery in
| the middle.
|
| I totally agree with you: the only useful delivery mechanism
| available is email. PGP was a nice idea and authenticator apps
| need to have their owner's heads bashed together to get proper
| interoperability sorted out. Trying to silo people in your
| "cloud" without interoperability with others is so sad and
| needy. If you don't have absolute confidence in your offering
| then you are shit!
| boneitis wrote:
| A little off-topic from the matter of adoption and usability
| by the greater masses, but I personally prefer these RFC 6238
| TOTPs that I have the choice to take into my own hands, as
| opposed to internet-required, server-side based like my
| banking app and Okta.
|
| I have a copy of all my TOTP generators (minus my dev Okta
| account) in a common authenticator app and an offline copy
| stored in an offline password manager, further replicated
| with an encrypted backup service.
|
| I was able to create my offline copy in the first place
| thanks to a rooted phone to export what I already had up to
| that point out of the authenticator app.
|
| Of course, the discussion starts to morph when we bring in
| the "un-phishable" software passkeys.
| firesteelrain wrote:
| I thought the Authenticator apps were great until I
| upgraded my iPhone and the apps lost all of my
| Authenticator setups. Good thing it wasn't super critical.
| unethical_ban wrote:
| I agree, for personal use cases, RFC standard TOTP that can
| be backed up and managed by the user is the ideal balance
| of security and availability.
|
| Enterprise TOTP apps like Okta and MS Authenticator have
| some enhancements. Push notifications are convenient when
| you have to access things many times a day. More
| importantly, push notifications with a number-matching
| confirmation reduces the chance of TOTP poaching, since the
| user themselves are interacting with the service requiring
| auth.
|
| In enterprise environments, there should be a restore
| process for a lost phone or authenticator. Some kind of
| backup code with voice/manager approval, or coming into a
| physical office to reset credentials. This isn't available
| for regular people/regular retail services except maybe
| banks, but banks can't even do regular TOTP correctly.
| jerf wrote:
| I'm increasingly coming around to the idea that in reality,
| there's only one factor, at least as far as the Internet is
| concerned: Something you know. There's different ways of
| knowing it and various difficulties involved in knowing it,
| but "something you are" is only every a fancy way of
| presenting something you know (because if you know it, you
| can generally forge it with reasonable effort) and "something
| you have", over the Internet, is just "something you know but
| is pretty difficult to directly extract".
|
| TOTP was what really kicked me into thinking this way. They
| tried to make it "something you have". They tried to lock it
| behind apps and pretended _really hard_ that it wasn 't just
| a particular shared secret... but it is. It's just something
| you know.
|
| The rule is, if it could be stuck in your password manager,
| it's a thing you know. That includes even things like
| Yubikeys, which are things that can be cloned and stuck in a
| password manager. They're just _really, really_ hard to
| clone, and that 's a valid step up from "a password". I'm not
| saying that the differences between all these "things you
| know" are irrelevant; they matter a lot. Having a password +
| a TOTP is a legitimate step up from having just either one
| alone. I'm just saying that analyzing things in terms of the
| other two factors isn't particularly relevant.
| bscphil wrote:
| I don't think this is right. If there's a shared secret
| like a TOTP seed, that's _in theory_ a "something you
| know", but if I _don 't_ know it, then who does? The point
| of "something you have" is that you own a _device_ that
| "knows" it for you, and you never even need to see or
| expose the underlying secret, you just copy a token proving
| that the device you have knows the secret. I think that
| does count as an additional factor.
|
| Of course if someone is memorizing the TOTP seed and
| generating the proof on the fly every time, then there's no
| shift in factor, but no one is doing that. And if they're
| saving the password on the same device that stores the TOTP
| code, then we're back to one factor, but now it's just 2x
| "something you have" at that point.
| marcosdumay wrote:
| Yes, if you don't control the hardware at the user's end,
| the only factor you can get is "something you know".
|
| All the things around improving web authentication are just
| about people not having to memorize that something you know
| and protecting it against eavesdroppers.
| kalleboo wrote:
| The way I see it, the main security benefit of TOTP is it's
| a very long, high-entropy password that is guaranteed to
| never be re-used.
| lxgr wrote:
| > That includes even things like Yubikeys, which are things
| that can be cloned and stuck in a password manager. They're
| just really, really hard to clone, and that's a valid step
| up from "a password".
|
| That's reductionist way past the point of being a useful
| model of authentication factors.
|
| By that logic, even biometric factors are "something you
| know", as you can always (with a lot of effort) physically
| replicate a fingerprint/retina/genome you have a
| sufficiently high fidelity recording of.
| tzs wrote:
| > To add insult to injury, MS Auth can only have one account
| per email address (id@realm/whatever you want to call it)
|
| When this was discussed [1] on HN a few weeks ago, I don't
| recall anyone reporting reproducing it. Several people,
| including me, reported having many accounts in MS
| Authenticator that have the same email address with no
| problem.
|
| The otpauth URI that is encoded in a TOTP QR code looks like
| this:
|
| otpauth://totp/LABEL?parameter_list
|
| The LABEL is supposed to serve as a unique identifier for the
| account. It has the format "Issuer:Account". The "Account"
| part is required. The "Issuer" is optional (and the ":"
| omitted if the issuer is not present).
|
| The parameter list is an & separated list of name=value
| pairs. It includes the "secret" parameter which gives the
| TOTP secret. An optional parameter is "issuer", which should
| match the "issuer" part of the label if that is present.
|
| It sounds like what is happening is that there are some sites
| who do not include the "issuer" part the the label, _and_
| they let the user use a user provided email address as the
| account name.
|
| If a given user uses two such sites and provides the same
| email address to both, then there will be a collision. If
| they also do not include an issuer parameter an authenticator
| app has no way to know just from the data in the codes that
| they are from different sites.
|
| [1] https://news.ycombinator.com/item?id=41275846
| j45 wrote:
| Passwords are consent, clicking on a link in an email account
| that might be open... not always.
| simonw wrote:
| > If the answer is "they just don't get access anymore" or "a
| panel of their peers attests to them", your fantasy
| authentication system also needs a fantasy species of sentient
| beings to serve as users, because it won't work for humans.
|
| This has been my single biggest argument against
| blockchain/cryptocurrency stuff for years: the "lose your key,
| lose your wallet" thing is fundamentally incompatible with real
| users.
|
| Humans need to be able to recover from their mistakes.
| j-bos wrote:
| I don't know, we carried physical money for millenia. Humans
| managed that.
| iamthepieman wrote:
| You didn't lose your entire savings if you lost your
| wallet, usually.
| onethought wrote:
| Perhaps micro wallets should be a thing where your wealth
| is distributed across many keys mitigating some loss.
| jakelazaroff wrote:
| If I'm having trouble juggling a single ball, why would
| it help to add more balls into the mix?
| ta_1138 wrote:
| At which point I gained the problem of having to keep
| track of all of my microwallets securely, hopefully in a
| way that survives my phone being lost, a house fire, or
| my untimely death, leaving the wealth to inheritors. All
| while, at the same time, not ending up behind a single
| key that has access to all the information to those micro
| wallets.
|
| Quickly you end up in a situation that either starts to
| look like how financial companies keep their most high
| risk keys, or end up outsourcing the whole thing to
| something that quickly starts to resemble your bank.
|
| So ultimately it's just like cash: Fine for small
| amounts. Risky, but maybe livable for somewhat larger
| accounts, or a giant headache that will probably bite you
| when you start looking at lifetime savings.
| IggleSniggle wrote:
| Physical money is physically recoverable after lost
| onethought wrote:
| No it isn't. No more than a wallet key.
|
| If I lose $1 note. It's gone. If I recover it, then it's
| no longer lost.
| MadnessASAP wrote:
| A $1 note being a macro scale physical object enjoys a
| variety of benefits such as object permanence which
| provide a baseline level of recoverability. Whereas a
| wallet key l, being a number, enjoys no such protections.
|
| Of course you may choose to encode your wallet key on
| paper, metal, or stone granting it properties not unlike
| a note. However you have now compromised the security of
| your wallet as well it becomes no mere $1 note, rather it
| is a note that represents all or a significant fraction
| of your net worth.
| zmgsabst wrote:
| You can encode your bitcoin in wallets of predetermined
| size, spreading your risk.
|
| But you're reinventing money with extra steps.
| Djdjur7373bb wrote:
| > But you're reinventing money with extra steps.
|
| But you gain some desirable properties over traditional
| money.
|
| Without crypto, you don't have frictionless and
| permissionless transfers of arbitrary value across
| international borders.
| SpicyLemonZest wrote:
| There's no fundamental property of the monetary system
| that prevents transfers of arbitrary value across
| international borders. There's just a large number of
| financial regulators, border guards, etc. who will throw
| you in jail if you carry a big block of gold across the
| border or accept a large wire transfer without filling
| out the necessary forms. In many countries, the laws
| governing those forms don't yet apply to
| cryptocurrencies, but I'm skeptical it will remain that
| way forever.
| Too wrote:
| For the system yes, a dropped coin eventually reenters
| the market and a burned bill can be reprinted again.
| Can't say the same about a crypto wallet. For an
| individual though, in both cases, a lost wallet is a lost
| wallet.
|
| While an interesting difference to study, the average
| person is not going to care about the former case. They
| just don't want to keep their life savings in an asset as
| easy to loose as their pocket money.
| IggleSniggle wrote:
| If you drop your wallet in a bar, there's a chance you
| can recover it by returning to the bar and searching for
| it, by the bartender or a patron returning it to you
| based on the address or a number in your wallet, etc.
| Physical money really is not the same, even for the
| individual.
| d0gsg0w00f wrote:
| A burned bill can be replaced because its value is backed
| by an institution--the absence of such an institution is
| the premise of crypto.
| blahedo wrote:
| Yes, by evolving banks to solve some of the problems of
| lugging around lots of cash and/or stuffing it in a trunk
| in your house. And assuming you are known at your bank
| and/or can (eventually) prove your identity there, you
| don't have the same "lost wallet" problem being discussed
| here.
| lolinder wrote:
| Money occupies physical space, so for most of history there
| was a pretty low cap on how much you could bring with you
| at once, which placed a cap on how much a single mistake
| could cost you.
| zmgsabst wrote:
| That cap has always and still does exceed the median
| worth.
| zaphirplane wrote:
| > cap on how much you could bring
|
| Bring to where ? Are you mapping the crypto wallet
| concept to the physical wallet concept as a mobile
| storage concept ?
|
| All your money is the limit, however you store it.
| ekianjo wrote:
| > there was a pretty low cap on how much you could bring
| with you at once,
|
| you didnt need to bring a case of cash to buy anything
| before the 20th century
| somenameforme wrote:
| Currency was traditionally made of precious metals which
| often gave them a rather high starting point of value. It
| also made them inflation resistant meaning the real value
| only grew over time. For instance in the Roman Empire an
| aureus [1] was worth 25 denarii (prior to inflation) and
| was about 2cm in size, so roughly the same size as a
| dime, made of pure gold. And a denarius was worth about a
| day's wages. So you could comfortably hold decades of
| wages in a small coin purse. And as inflation ravaged the
| Empire a single aureus gradually came to be worth
| thousands of denarii.
|
| [1] - https://en.wikipedia.org/wiki/Aureus
| presentation wrote:
| This is what transit payment cards in Japan at least do,
| you can tap to pay most places but there's a cap of 20k
| yen you can add to your card, so there's a cap to how
| much you can lose.
| umanwizard wrote:
| Yeah and it sucked which is why we invented better
| solutions.
|
| What most bitcoin fans seem not to understand is that for
| the vast majority of people, transactions being reversible
| by authority figures is desirable.
| lelanthran wrote:
| > I don't know, we carried physical money for millenia.
| Humans managed that.
|
| Yeah, but if I lose the physical 100$ I am carrying, that
| doesn't prevent me from accessing the rest of my cash
| stored elsewhere.
|
| I've never lost access to the rest of my cash stored
| elsewhere.
| alkonaut wrote:
| Yes and people quickly realized that there is an amount
| they don't want to carry around. No one carries their life
| savings and few would even keep it in a safe in their
| house.
| paxys wrote:
| Banks have been a thing almost as long as money.
| kibwen wrote:
| And the notion of credit has been a thing even longer
| than both money and banks. You don't need to carry money
| around for every little transaction if people know you're
| good for it someday in the the future.
| rendaw wrote:
| I've heard that a lot about cryptocurrency, but aren't there
| plenty of cryptocurrency users who have never lost their
| wallet and have good personal opsec?
|
| Maybe the issue is trying to force one solution for everyone.
| airstrike wrote:
| The claim that most humans are prone to losing keys isn't
| negated by the existence of some humans that have (so far)
| been able to keep their keys.
| wpm wrote:
| The issue in not trying to force one solution for everyone
| becomes a blocker when you intend on making some technology
| useful and essential to everyone, hence, no one seriously
| gives a damn about crypto anymore.
| rblatz wrote:
| Even Bitcoin core developers, which should be well above
| average in understanding crypto and good opsec, have had
| their Bitcoin stolen.
| nick3443 wrote:
| Maybe instead of a crypto brokerage holding your wallet,
| there can be a "key bank" which uses those more expensive
| methods of attestation and you can use it for recovery if you
| lose your key up to once per year or something. It would be
| like having your key written down in a safety deposit box at
| a local or regional bank.
| firesteelrain wrote:
| This is the same problem that you run into with secret zero
| and commonly discussed in context of HashiCorp Vault. At
| some point you need to store the unlock keys then you need
| another repository under RBAC to protect that repository.
| They say to print out the keys and store them offline on
| paper but how many own a Class 5 safe ?
| tasuki wrote:
| How many own a lot of books? Just... pick one.
| firesteelrain wrote:
| Not following? Do you know what I meant by a Class 5
| safe?
|
| https://www.norfolksafe.com/
| tasuki wrote:
| I don't. And frankly I don't think a safe is a good place
| to store secrets. It is too conspicuous.
| firesteelrain wrote:
| These safes are certified for all kinds of sensitive (GSA
| recommends them for Classified use from what I have read)
| use and they are safe.
|
| Ideally, you connect Vault to a HSM if you need that kind
| of security that's being described. HSMs are electronic
| safes
| tasuki wrote:
| > These safes are certified for classified use and they
| are safe.
|
| The website says "10 minutes against forced entry".
| That's not safe.
|
| No safe is safe against a state level actor. No safe is
| safe against "hit you with a crowbar until you open the
| safe".
|
| Whatever secrets you have, it's better to hide them than
| to put them in such a conspicuous place. The only reason
| one should use a safe is as a plausible decoy...
| firesteelrain wrote:
| This isn't the safe to rule all safes. You have other
| mitigating factors like access control.
|
| If you have state level actors physically breaking into
| your facilities then we might be at war
| tasuki wrote:
| If you have enough books (which doesn't even have to be
| that many), it's much better to store your secrets in one
| or more of the books.
| firesteelrain wrote:
| Yea but you have multiple pieces of the secret to restart
| your Vault instance. Now you need to go to everyone's
| office or home to get this secret to restore it.
|
| I am referring to Shamir algorithm that Vault uses
| grey-area wrote:
| Maybe the key bank could hold your digital money as well.
| Then we wouldn't need a blockchain and your transactions
| could be instant, free, private and reversible.
| thinkmassive wrote:
| Collaborative custody multisig providers have been in
| business for years. Recently even Block (CashApp etc) has
| introduced a product with this feature.
|
| By geographically distributing your signing devices you
| improve both security and reliability. One of those keys
| can be hosted by a third party to be used for recovery,
| without providing them any ability to touch your funds
| without your involvement.
| thaumasiotes wrote:
| > This has been my single biggest argument against
| blockchain/cryptocurrency stuff for years: the "lose your
| key, lose your wallet" thing is fundamentally incompatible
| with real users.
|
| This would make currency fundamentally incompatible with real
| users. Reality says otherwise.
| jacinda wrote:
| Currency in the real world has many, many backups. For
| example, if I forgot the PIN number to a very old bank
| account that I later find a long lost relative recently put
| hundreds of thousands of dollars into when they passed
| away, I have other avenues to recover access. They might be
| annoying or require work (getting an affidavit, multiple
| forms of ID, etc) but it's not irrevocable in the way that
| a strict definition of bitcoin is.
| xboxnolifes wrote:
| A bank account is not currency. Cash is. You can still
| put cryptocurrency in a bank if you so choose.
| jjmarr wrote:
| It's a lot harder for the average person to lose 1
| million dollars in cash than in Bitcoin because humans
| naturally understand the exchange of physical objects.
|
| If I have a duffel bag of money, it is obvious that
| physical possession of the bills means I can access its
| value. Anything negating that possession would cost me my
| money. I should probably keep it away from open flames
| and water; but it's not going to spontaneously combust. A
| thief would need to physically take the money in the
| duffel bag for me to lose the value.
|
| Meanwhile if I store Bitcoin on a USB drive the drive
| might randomly fail and I lose all my money (because I'm
| actually storing a key to access it) even though I still
| have the USB stick. The solution is to back up my key in
| multiple places simultaneously, which doesn't make sense
| to most people (how can money be in two places at once?)
|
| If I plug the USB stick into the wrong computer, someone
| can steal all my money (because they can find out what
| the key is) without me ever losing the USB stick.
|
| Virtually every human on Earth understands the notions of
| object permanence and that objects can be exchanged for
| other objects. This is intuitive from evolution and
| actual monkeys can comprehend physical currency.[1] I
| don't see how cryptocurrency can be on that level.
|
| [1]. https://www.zmescience.com/research/how-scientists-
| tught-mon...
| fragmede wrote:
| The concept that this file is the password to the money
| isn't too complicated. The money isn't in two places at
| once, the file's the password to it.
| XajniN wrote:
| It's impossible to comprehend to most people.
| eesmith wrote:
| Except reality isn't so ... digital.
|
| In reality I've found a lost wallet and helped return it to
| its owner. At least twice, actually. Both times because
| there was an identifying name in the wallet.
|
| Then there's the time as a kid when we found $60 on the
| floor at a department store, and turned it over to
| lost&found. I remember it because the store had a policy
| that if cash hadn't been claimed for a month, then the
| person who turned it in got it. Which we did.
| soerxpso wrote:
| > the "lose your key, lose your wallet" thing is
| fundamentally incompatible with real users.
|
| You're allowed to store your key at the bank if this is an
| issue for you. It's less secure than memorizing it, but
| obviously equally as secure as your bank account is.
| throwaway290 wrote:
| It is not equally secure, if bank loses you money you have
| recourse, if bank loses your key (a fire, a flood) it's
| gone.
| perceptronas wrote:
| You can store it in two or N places. Or bank can do this
| for you.
| throwaway290 wrote:
| More places is more opportunities for the baddies to get
| it.
| kriops wrote:
| Shamir it.
| sulandor wrote:
| please wrap the whole thing as a trustworthy product
| cooljoseph wrote:
| I don't understand why this was downvoted. In case it's
| not clear: (S)he's saying to split the key into multiple
| shares that can be used to reconstruct the key if you
| have a large enough quorum. Then store each share in a
| different place. As long as you don't lose too many of
| the shares, you'll be fine. And one baddie is NOT enough
| to get the key.
| throwaway290 wrote:
| Either shuffling those keys stored in N different deposit
| boxes is overly complicated for a normal person, or it is
| not overly complicated for a moderately dedicated baddie
| either
| Djdjur7373bb wrote:
| Unless the "baddie" in this case is the government, why
| would it be easy for anyone to obtain access to multiple
| secrets stored in multiple boxes/banks?
|
| Multisig is a pretty common setup for crypto and there is
| software that makes it easier.
| notfed wrote:
| "Mom, I already told you: you have to generate a key
| pair, split the private key into three parts using
| Shamir' secret sharing algorithm, then give each part to
| three banks. Whenever you want to use it, you have to go
| collect it from each of those banks---but DON'T write it
| down anywhere---and perform your transaction"
|
| And to think the conversation started with an observation
| that people can't even remember one password.
| afastow wrote:
| I stay away from everything crypto but I don't see the
| difference. In both cases if they didn't make it right
| you'd go to the courts and make your case that they are
| at fault and owe you compensation.
| kgwgk wrote:
| In the first case, bank deposits are insured. In the
| second case, safe deposit boxes are not insured.
| afastow wrote:
| They're just different things. The FDIC insurance is for
| if the bank itself goes insolvent and they literally
| don't have enough money to cover their depositors'
| balances anymore. There's no reason a safe deposit box
| would be affected.
| throwaway290 wrote:
| A fire, a flood, a robbery...
| bburnett44 wrote:
| Is a bank deposit box not insured against those things?
| I've never really thought about it but always assumed
| they would be
| dagw wrote:
| Probably varies from bank to bank, but in my experience
| you have to specifically buy separate insurance if you
| want the content of your deposit box insured. The big
| problem from the bank's point of view is that, unlike
| your bank account, the bank doesn't know what you have in
| the box and thus has no idea what to insure it for and no
| way to verify any claim.
| kgwgk wrote:
| Yes, they are different things. A safe deposit box
| wouldn't be affected by the banks insolvency.
|
| A safe deposit box may be affected by other things and if
| those things happen they don't have to "make it right",
| if you go to the courts and make your case you may find
| that they are not at fault and you are not owed any
| compensation.
| btilly wrote:
| The history of crypto says, "Good luck!"
|
| There is a long history here of once trusted institutions
| turning out to be fraudulent.
| generic92034 wrote:
| I might be mistaken, but are not several "traditional"
| banks offering crypto wallets for customers? Is there a
| realistic chance this kind of bank is going to steal their
| customers' crypto and going (at least, next to criminal
| investigations) bankrupt over it?
| Djdjur7373bb wrote:
| Sure, they could. Would that be any different from how a
| bank could steal funds from a traditional deposit
| account?
|
| By making a bank the custodian of your crypto wallet,
| you're placing your trust in them and should have similar
| legal recourse you would have had with a fiat deposit.
| generic92034 wrote:
| I am not sure if you are objecting. Definitely you need
| to trust your bank if you are going store your crypto
| with them. I just do not see any large traditional bank
| stealing their customers' crypto and hoping to get away
| with it.
|
| As far as I know all the cases of stolen crypto have been
| newly founded companies with their only business being
| your crypto. That is quite unlike the other kind of bank.
| cortic wrote:
| >> If the answer is "they just don't get access anymore" or
| "a panel of their peers attests to them", your fantasy
| authentication system also needs a fantasy species of
| sentient beings to serve as users, because it won't work for
| humans.
|
| >This has been my single biggest argument against _fiat
| currency_ stuff for years: the "lose your money, lose your
| money" thing is fundamentally incompatible with real users.
| Humans need to be able to recover from their mistakes.
|
| And yet, for the very longest time, it was the default
| position for humans.
| comprev wrote:
| If you accidentally burn cash you cannot recover it. The
| paper in your hand isn't replicated in another place.
|
| Humans have been unable to recover from mistakes since day
| zero
| dotancohen wrote:
| For at least 12,000 years, humans have been getting very
| good at holding on to physical things.
|
| Digital things, not so much. I'm a professional in the
| field, yet I've lost digital data in the past few years.
| Normal users who work in other fields? Lost cause.
| depaya wrote:
| That is a funny example to use because the US Government
| has a service specifically designed to help you in that
| situation: https://www.bep.gov/services/mutilated-currency-
| redemption
|
| Yes obviously if your money is completely burned then it's
| gone, but that is generally pretty unlikely to happen.
| Losing your digital key is many orders of magnitude more
| likely to happen in my opinion. And there is - by design -
| absolutely no way to get it back. That makes using
| blockchain for anything serious completely untenable in my
| opinion.
| andresgottlieb wrote:
| It doesn't need to be completely burned to be gone:
|
| "No redemption will be made when (...) Fragments and
| remnants presented which represent 50% or less of a note
| are identifiable as United States currency but the method
| of destruction and supporting evidence do not satisfy the
| Treasury that the missing portion has been totally
| destroyed"
|
| Not that unlikely, in my opinion.
| mvitorino wrote:
| Accidentally burning money is a very low probably event.
| Forgetting passwords or any type of memorized secret is the
| most likely default outcome, and chance only increases with
| time passing.
| sealeck wrote:
| > If you accidentally burn cash you cannot recover it. The
| paper in your hand isn't replicated in another place.
|
| Which is (one reason) why most people use a bank account
| and don't hide their money in big bundle of cash under
| their pillow?
| drdaeman wrote:
| > [...] the "lose your key, lose your wallet" thing is
| fundamentally incompatible with real users. Humans need to be
| able to recover from their mistakes.
|
| Maybe it's my memory playing tricks, or I've only seen the
| good articles, but I believe nearly every single article
| about setting up a self-managed crypto wallet had stressed
| out the importance of having a backup. Serious ones had even
| explained the 3-2-1 rule. Then the hype came, with it came
| scams and pumps-and-dumps and NFTs and whatever, and crypto
| became a clusterfuck that a lot of people didn't want to
| touch. Yuck.
|
| That's probably the one thing cryptocurrency communities
| undeniably got right. Quite unlike the Passkeys, where I've
| yet to see any official or semi-official demo site that even
| has a flow for adding a second token (some actual sites do,
| but not the demos).
|
| We should start teaching basic backup strategies in schools.
| It's not some advanced rocket science, and it's a knowledge
| that's useful to anyone who deals with information (that is,
| literally anyone participating in the modern society).
|
| Also, this user unfriendliness is extremely temporary,
| because computers and Internet are new (at the scale of
| societies), and there are plenty of folks who had only
| started to use them later in their lives. After you lose some
| file or account (ideally, as a kid, so it's not something
| serious) you start to understand the old adage about those
| whose do backups and those who don't do them _yet_.
| antifa wrote:
| How many forms of backup survive "the government threw you
| in prison for years?" Even Gmail will refuse to
| authenticate a correct password with "we couldn't verify it
| was you" if you never binded your account to a phone and
| just got out of prison 3 years later.
| drdaeman wrote:
| Uh, well, in context of crypto - your (self-owned) crypto
| wallet totally would work.
|
| As for email... Sure, I guess it depends on the service
| and their policies. But here's an anecdote. A few years
| ago, I've managed to log in in to a completely forgotten
| 10+ years old email account, finding its password in an
| old backup. It worked. -\\(tsu)/-
|
| If an user cannot log in with a valid credentials,
| without brute-forcing them, after some years of absence,
| it's absolutely the service's fault. Of course, in the
| modern world, customer issues mean nothing so anything
| goes. But -quoting GP post - when designing a "fantasy
| football" alternate authentication system for the
| Internet, this probably shouldn't be a thing.
| karmajunkie wrote:
| i think you're sidestepping the parent's point: if it
| depends on users doing the right thing every time, it's not
| compatible with the real world.
|
| yes, the advice about wallets is "make a backup". the
| advice about passwords is "don't reuse them", yet the VAST
| majority of users use the same password for banking, email,
| and their phone provider. so what do you think the chances
| are that your average user makes a backup of their wallet
| AND remember where it is in three years?
|
| pretty much zero.
| Vegenoid wrote:
| > I believe nearly every single article about setting up a
| self-managed crypto wallet had stressed out the importance
| of having a backup. Serious ones had even explained the
| 3-2-1 rule.
|
| Yes, this is why it is incompatible with widespread
| adoption. Most people do not want to do this, and in fact
| could not do so effectively without learning and thinking a
| good deal more about computers and risk scenarios, which
| they don't want to do and will not do.
|
| You are correct that it is a solution. However, it is not a
| solution that will ever be adopted on a wide scale.
| rahimnathwani wrote:
| If the answer is "they just don't get access anymore" or "a
| panel of their peers attests to them", your fantasy
| authentication system also needs a fantasy species of sentient
| beings to serve as users, because it won't work for humans.
|
| It won't work for 99.99% of services, but it can work if your
| service is huge. WeChat uses a mechanism like this, and it
| works well.
| 8organicbits wrote:
| I'm not familiar, which part of the comment does WeChat
| implement?
| rahimnathwani wrote:
| A panel of peers.
| rakkhi wrote:
| Maybe we should support logging in with an OTP to email for
| many more systems than we do currently? Combined with
| conditional access and MFA its actually not bad.
|
| No password to remember and supports this "pattern"
| lxgr wrote:
| Sure, but please make it optional.
|
| I've seen a couple of enterprise/corporate services switch to
| the "OTP via email" pattern (usually as mandatory 2FA), and I
| hate it, because there's no way for me to autofill that email
| OTP, unlike for e.g. WebAuthN or TOTP.
| ReptileMan wrote:
| >Phone numbers are more common and durable, but the security of
| phone numbers is leagues below that of a flagship provider
| email account.
|
| With the - "we banned your account for no reason, and you have
| no way to appeal and we don't even tell you why we banned you"
| flagship provider email account caveat.
| AlienRobot wrote:
| This is my gripe with 2 factor authentication: it increases
| security and as a second factor also increases the risk of you
| losing your account.
| ivanjermakov wrote:
| I never thought of using password reset as a permanent
| authentication method. Ingenious!
|
| Except when the service throws you back to the login page to
| authenticate with a fresh password you just typed in the reset
| form.
| tptacek wrote:
| Plenty of services do this already, right? It's called "Magic
| link" login. Am I missing a subtlety?
| ivanjermakov wrote:
| In my recent experience it's 50/50.
| jonnycomputer wrote:
| As long as the email account is secure, and the throw-away one-
| time passwords are good, you have the frequent-rotation passwords
| security advocates dream about. Indeed, hand them a secure
| password they have to use (and forget).
| voiper1 wrote:
| I just made it an option in the "I don't have a password" form
| that instead of setting a password it just logs them in. So
| they don't even see / have a password to remember.
| prng2021 wrote:
| "It offers a guaranteed, repeatable, low-effort solution"
|
| Doesn't this answer the question? I would have preferred to read
| and discuss what they believe to be better alternatives.
| Terretta wrote:
| > _whether we can take advantage of people's tendencies towards
| learned behaviour like this_
|
| See, thoughts like that turn into billion dollar valuations at
| Series B for, among other things, a login button that emails
| you a login link, taking advantage of people's tendencies
| towards behavior like this:
|
| https://stytch.com/products/email-magic-links
|
| https://stytch.com/blog/announcing-series-b/
|
| (Or maybe turn into Tell HN posts on common SaaS vulns, like
| https://news.ycombinator.com/item?id=33162854, but point is
| lots of companies offer this including most SaaS-y IdPs,
| search: _passwordless email magic link_ , it's not new:
| https://auth0.com/blog/auth0-passwordless-email-authenticati...
| ...)
| Hugsun wrote:
| You posit a good question but it would be interesting to take a
| step further and discuss some potential alternatives, or expand
| on why "email is authentication" is/isn't the best option there
| is.
| paulgerhardt wrote:
| I'll be hyperbolic and say the login flow is identical.
|
| A) Go to website, click through a password manager to copy and
| paste an arbitrary string of characters, receive TOTP request
| sent to your email to confirm your identity.
|
| Or
|
| B) Go to website, click forgot my password. Receive link to
| login. Enter an arbitrary string of characters.
|
| In many instances, login flow B is actually quicker and seldom
| slower.
|
| Clicking the "remember me" checkbox has no effect.
| MBCook wrote:
| Who copy and pastes from a password manager?
|
| Here's my workflow, and I consider it superior to both of the
| above.
|
| Go to site, Safari offers to autofill, give TouchID/FaceID, get
| asked for a 2 factor code.
|
| Sent via SMS/email? Safari offers to autofill for me. TOTP
| style? Safari offers to autofill for me.
|
| Easy peasy.
|
| Passkeys are even easier as there is no second step and waiting
| for SMS/email.
| bigstrat2003 wrote:
| > Who copy and pastes from a password manager?
|
| People who don't use something which integrates with the
| browser. People who run into the (uncommon but noticeable)
| edge cases where the password manager decides to not auto
| fill the password.
| MBCook wrote:
| When it doesn't work I get. I run into that from time to
| time.
|
| But I don't think normal users want ones that don't sync or
| integrate with the browser. I believe you can turn both off
| for Safari but that defeats the whole purpose in my mind.
| paulgerhardt wrote:
| Yes, that is a nice solution.
|
| I suppose the reason is because the Bitwarden option is cross
| platform and I don't want to sync two password managers.
|
| However when using Bitwarden the recent guidance is to turn
| off autofill[1] but even with it enabled it sometimes breaks
| hence my "seldom" caveat.
|
| I am heavily biased to prefer passkeys but as with magiclinks
| before them saw the rollout was badly botched. Specifically
| with regards to supporting multiple keys and
| revocation[2][3]. The standard supports correct
| implementation but don't require it; meaning most current
| rollouts are half baked and will remain that way.
|
| [1] https://flashpoint.io/blog/bitwarden-password-pilfering/
|
| [2] ie: https://www.reddit.com/r/yubikey/comments/14h0d7y/sin
| gle_key...
|
| [3] https://news.ycombinator.com/item?id=40165998
| Rygian wrote:
| > Who copy and pastes from a password manager?
|
| Me. I don't know of any other LAN-only method that works
| consistently across my various desktop and mobile devices.
| fragmede wrote:
| okay, but you're using xclip/pbpaste/equivalent, yeah?
| Rygian wrote:
| Ctrl-C and Ctrl-V work consistently on Windows + Linux.
| For Android, almost same experience with KeePassDroid
| that shows notifications to Ctrl-C the user and the
| password.
| Fabricio20 wrote:
| > Who copy and pastes from a password manager?
|
| I do! And way more than I would like, because for some reason
| it's "modern" to have a login flow that first requests your
| email, and then you have to click next for it to request your
| password...
|
| Not even gonna go into detail about all the other cases like
| websites that have such bad field identification that the
| password manager has no clue where to put the username/email
| or 99% of sites that don't have autocomplete="one-time-code"
| on the 2FA field so now you have to copy paste the 2fa.
|
| Plus all the android buggyness where the auto-complete from
| the password manager just doesn't show up at all so you have
| to switch apps and copy/paste the credentials manually...
| when it works (and doesn't clear the fields as you swap
| between apps... I swear built-in chrome windows is a
| mistake).
| abdullahkhalids wrote:
| Keepassxc's desktop browser extension allows you to specify
| the username and password boxes. Even if they are on
| separate pages. It's really a painless 15 second process.
|
| I have to do it on my bank's website every few months.
| lelanthran wrote:
| > And way more than I would like, because for some reason
| it's "modern" to have a login flow that first requests your
| email, and then you have to click next for it to request
| your password...
|
| There's a reason for that, and it's not because of
| 'trendy', it's because the backend will examine the email
| address and decide which password authentication mechanism
| the user chose: FB/Google/etc, or authenticator app, or
| plain old password, or some third-party SSO provider, etc.
| lxgr wrote:
| Me, every time another site annoyingly breaks autofill,
| sometimes even intentionally ("Password managers not allowed!
| Make sure to memorize your password, but still use at least 5
| special characters and include at least 3 titles of ABBA
| songs!!").
| kwhitefoot wrote:
| Doesn't your browser remember your passwords?
| drekipus wrote:
| my wife chooses not to let chrome remember her passwords
| because she thinks it's lazy and insecure: everyone uses
| chrome, how will chrome know not to give her password to
| someone else?
| vultour wrote:
| But she is right, unlike your password manager the browser
| has to store it unencrypted because nobody bothers with
| setting the master password.
| fragmede wrote:
| This flow is made shorter if you have the TOTP stored and
| filled out by the password manager.
| dishsoap wrote:
| TOTP is not really something that would be sent to your email.
| The entire point of TOTP is that you can generate the auth code
| yourself, from the current time and a pre-shared secret.
| kevincox wrote:
| I think the OP meant OTP. The general concept of one time
| passcodes, not TOTP as per RFC 6238
| zajio1am wrote:
| With greylisting, the flow B could take like 10 minutes.
| bsder wrote:
| > B) Go to website, click forgot my password. Receive link to
| login. Enter an arbitrary string of characters.
|
| > In many instances, login flow B is actually quicker and
| seldom slower.
|
| And B) can be accessed whereever I have email and doesn't need
| either an app or my phone which may or may not be on my person.
| cyrnel wrote:
| Somewhat related discussion from yesterday:
| https://news.ycombinator.com/item?id=41468486
| jwr wrote:
| Some apps enforce this flow, e.g. there is no way to log in with
| a password. I hate this.
|
| Because of the developers of these apps assuming that E-mail
| guarantees instant delivery (it doesn't), I can't use
| greylisting, which reduced spam very significantly.
| mgkimsal wrote:
| Amen, yes. Greylister here too, and password reset/magic links
| sometimes end up being painfully slow.
| yencabulator wrote:
| Your greylist setup really should learn good senders quicker;
| this shouldn't be an ongoing problem.
| TZubiri wrote:
| Because websites used emails as an identity, strictly in order to
| stop malicious use.
|
| An email ties a user to a domain, the domain issues a user for
| them. If too many users from a domain are malicious, the website
| can block the domain.
|
| It's a matter of identity and accountability.
| hnick wrote:
| Too many don't actually verify the identity. I often get emails
| lying in the footer with something like "you are receiving
| these emails because you signed up" - no I didn't, someone else
| did, and you didn't check. But fast onboarding is king, right?
|
| And then the unsubscribe, close account, or basic support is
| all locked behind the login, or it's an international phone
| call. As far as I know, even if it's my email it's not legally
| my account so signing in would be illegal.
| dogcomplex wrote:
| At this point why not just pass a one-time url link to your email
| address, and have it be a single click to login? Have it expire
| within 10 mins if not used, and be one-time use disposable.
| Still, anyone who has the link initially should be able to login
| with your account - but it's only accessible from your email.
|
| Obliterates all sense of security beyond the email account
| itself, but that's where we're at anyway. Do the same pattern
| with a message to your phone "click to authenticate login:
| www.someurl.com?p=134234535" and you've got 2FA without any dumb
| "enter this code".
| fragmede wrote:
| There are a number of sites that do exactly that.
| sunnybeetroot wrote:
| I agree this is a great way but don't forget not everyone is
| signed into email on their device.
| Saris wrote:
| Some sites do that, like Netdata.
|
| But it's slow compared to my PW manager just autofilling a
| user/PW combo, since I have to wait for the email and go click
| the link.
| EasyMark wrote:
| Yep, I really hate when I have to go to email to get a
| verification code or click link to verify. I have a password
| keeper and 2fa for a reason. I hate the wait.
| byteflip wrote:
| I'm coding up a webapp with this exact login process - the
| issue I've found is on mobile phones - apps like gmail won't
| let you copy the link into a browser without a preview. The
| preview consumes the link. (next.js auth)
|
| It's a bit annoying, since I don't want to login into the gmail
| in-app browser, I want to login on my regular browser.
| aetherspawn wrote:
| Don't forget some people have antivirus scanners that will
| load up every link when the email is opened, so you can't
| have the link expire after 1 visit.
|
| This is I think why unsubscribe links now have a single
| button saying "Unsubscribe" or similar when you press them.
| Likewise anything interesting should require a 2nd user
| action after loading the page.
| righthand wrote:
| A work around could be: login link token is good for 24hours
| unused, or 5mins after the first use. That way you don't
| leave the user in a loop or risk them not clicking the link
| within a short amount of time. The token still expires after
| a reasonable duration too.
| klabb3 wrote:
| Yes easy mistake to make. But this goes back to HTTP basics:
| a GET request shouldn't mutate state. Either don't consume
| the link (ie allow reuse), have a user confirm action with
| POST, send a code instead. There are many alternatives.
|
| Personal favorite? Send a 6-digit code with ~1h expiry,
| exchange for a refresh token and keep the session for a long
| time. If you have really high value irreversible actions then
| you can just confirm with a new code.
|
| Also works if mail client is on a different device.
| archerx wrote:
| I will be sure not never use your webapp just because of the
| email login system.
| adastra22 wrote:
| Pleas don't force this login method. It is extremely annoying
| for anyone with a non-standard email setup (often for
| security reasons), and is slow as all hell.
|
| Why make things worse for your users?
| stavros wrote:
| I do this for many of my web apps, it's confusing to users
| ("why do I already have an account here? I never signed up!"),
| expensive (email sending isn't free) and slow (sometimes the
| emails go to spam, sometimes they get greylisted and people
| can't log in for hours, sometimes it takes a minute to arrive
| and that's way too long to wait), etc. I don't know if I'd
| recommend it.
| echoangle wrote:
| Can you elaborate on ,,email sending isn't free"? What are
| you using to host the webapp? Can't you just set up your own
| mail server and send whatever you want?
| imron wrote:
| Generally, no, unless you don't care whether it's delivered
| or not
|
| Too many people and companies abused this to the point that
| running your own mail server means much of the generic mail
| you send will end up in junk/spam folders.
| fooker wrote:
| It won't even be delivered in most cases.
| echoangle wrote:
| What would prevent delivery? I do some work for a small
| organization and we send out registration confirmations
| with a self-hosted webserver. I am not aware of any
| delivery problems there. Thats why I was surprised. Are
| we just lucky?
| m3047 wrote:
| You are just lucky. You can contact me if you want to
| discuss further, I would strongly recommend you don't do
| it here.
| echoangle wrote:
| For a login link, I wouldnt really care if its in the
| spam folder. The person is actively looking for the mail,
| surely they will find it? It's different for marketing or
| similar content, but for expected mail, I wouldn't care.
| stavros wrote:
| You'd be surprised at how many messages I've gotten about
| expected emails not arriving, only for them to say "oh
| yeah, it _was_ in spam, thanks! ".
| arnaudsm wrote:
| I worked on email delivery systems. Your comment makes me
| realize that something that was free and trivial in the 90s
| is now painfully complex and expensive, because of
| monopolistic practices and spammers. We ruined something
| great.
| m3047 wrote:
| A lot of email reputation at this point, in fact I'd say
| most of it, is FUD. Here is a current example I am a
| hostage of:
|
| Sys4 (an ESP) uses Abusix as a reputation service.
| Because this is poorly thought out (I've been a member of
| the mailing list for many years) I can't unsubscribe from
| the postfix-users@ mailing list (can't post either). Ok
| that's weird and funny in a way. We could talk about
| Sys4's procedural failures which go into it but we would
| be here all day.
|
| I did Abusix's PYLM and they unblocked me, only to
| eventually block me again; that's when I found out I
| couldn't unsubscribe. I could PYLM again but I don't
| care. But that gave them an email address in the domain
| that they block. Do you see where this is going yet? I
| promise you there will be a twist at the end!
|
| Funny thing is, I can send email to support@. Well, ok,
| so I think it's probably good that they don't subject
| their support channel to their dog food, because third
| parties reporting vulnerabilities is a trope in
| cybersecurity.
|
| Aaand, here we go. So last week they sent UCE to that
| email address. That's right: they sent a marketing email
| to a domain that they block. I did not check any boxes
| "please, I'm a hostage, send me your marketing info and
| saaaave meeeee!" when I was talking to their support
| about what I could provide to my ISP. No boxes are
| checked now either, I verified this.
|
| So, I responded to that email and said I'd be delighted
| to learn more about their product, please have Sales
| contact me. The marketing SPAM came from support@, the
| reply from Sales came from a person's email. Now we're no
| longer talking about that hypothetically exempt support@
| channel, we're talking about corporate infrastructure. If
| their dog food is so good:
|
| * Why is corp accepting email from a domain they block?
|
| * Why is Sales sending email to a domain they block?
|
| Here's the twist I promised you:
|
| Do a DNS lookup for their MX: it's Google! They don't eat
| their own dog food, at all! Google has no problem with my
| domain; that's a general observation. If Google doesn't
| use their reputation service, why should you?
|
| For the skeptical:
| http://athena.m3047.net/pub/soe/abusix-spam-
| backstory.html
|
| My call with their Sales department is tomorrow morning;
| should be good times.
| Pooge wrote:
| I _hate_ when services only use SMS for 2FA. Sometimes I have
| to stare at my messages for a few dozen seconds to get the
| code, but with standard 2FA it takes me half a dozen seconds
| to unlock my phone and get the code.
| j45 wrote:
| A pattern to make signups faster doesn't make them secure.
|
| Magic links can be more like convenience links, not secure, or
| security.
| hn_throwaway_99 wrote:
| I'd argue at this point that magic links are _more_ secure:
|
| 1. Nearly every online service needs some sort of "forgot
| password" flow, and often times that flows boils down to what
| is essentially a magic link like TFA is about.
|
| 2. The vast majority of users these days use either personal
| email accounts from one of the big providers (Google, Yahoo,
| MS), or they use corporate accounts often through a hosted
| solution. 9 times out of 10 I'd bet the email provider has
| better security than whatever rinky dink website you may be
| creating an account on.
|
| Emailing magic links is essentially "poor man's SSO". It
| makes much more sense IMO to have super secure email accounts
| (e.g. ideally with passkeys) and then just use magic links
| for everything else.
| j45 wrote:
| Learning how to password effectively is something that
| comes up in B2B in many non trivial software.
|
| Magic link is effectively passwordless login, behind a
| facade outsourced to a third party provider.
|
| Passwords are much more actual consent, than clicking on a
| link in an email account that might be open on a screen or
| device... not always.
|
| SSO is technically easier than poor man's sso, it's just
| one click once logged in. Magic links make me switch a
| screen to make it easier for the developers of Magic Link
| to not implement SSO.
|
| Fingerprints are a username, not a username+password. It's
| super convenient, but well established not secure.
|
| Face-ID logins are more a username, should not be a
| username+password - selling it as secure is not ideal, but
| it is super convenient.
|
| SMS verifications too, are a little weak, since SMS'
| generally are like post cards. But they are very
| convenient. Until someone does something to get malware
| into your phone, or your phone number itself which seems to
| happen so often.
|
| Now, magic links are very convenient. And definitely can
| remove friction to you know, get a user onboarding to the
| point of adoption.
| layer8 wrote:
| Because it's still quicker or more convenient to use a password
| if you remember it or use a password manager.
| dugite-code wrote:
| > Have it expire within 10 mins if not used
|
| Please never do this short amount of time. Email isn't reliable
| time-wise for delivery. You have systems like Postgrey (one of
| the basic spam protections for email servers) and deliberately
| pretends the email server is offline for emails from new
| servers until they server retries a set number of times.
|
| Not to mention if your email ends up in a corporate quarantine
| until you can request it released.
| suprjami wrote:
| I use a web service which does this. It's mildly annoying
| having to switch apps/tabs just to login, but hey at least it's
| not another password to remember.
| archerx wrote:
| Remembering passwords is easy this is just just convoluted
| and stupid.
| mewpmewp2 wrote:
| Since you wouldn't want to reuse passwords how is it to
| remember them?
| antimemetics wrote:
| Let the machine do the work, sit back, and relax You have
| to remember 0 passwords and can still have a unique one
| for every account
| archerx wrote:
| Base password plus company name or initials. One password
| mutated into infinite variations that are easy to
| remember. This has been working fine for me for at least
| 15 years.
| suprjami wrote:
| What do you use for the base password? The website name?
|
| So if someone finds out your password for a certain site
| is `Facebook1234ABCD` they have a fair guess at every
| other password?
|
| Same applies for `MyPasswordFB` using the reverse method.
| archerx wrote:
| My base password is secret but it is an alpha numeric
| string with mixed caps. An example would be "p45Sw0rD-
| Apple+" something in that vain.
|
| So in the end the password contains numbers, letters both
| capped and lower case and special characters.
| system33- wrote:
| I think their point is that no matter how secure your
| base password is, once one site leaks it, the bad guy
| basically knows your password to every site.
| archerx wrote:
| I have been using the internet since the 90s, my Hotmail
| account is 23 years old and I have never lost any of my
| accounts. I think it's working quite well in my
| experience.
| suprjami wrote:
| It will, right up until the day it doesn't.
|
| You just need one little website to leak passwords in
| plaintext and all your passwords are up for grabs.
|
| I used to do the same thing and I stopped for that
| reason.
| homebrewer wrote:
| You'll be surprised how many diceware passwords you're
| able to remember.
|
| It can go two ways depending on your preferences: use a
| shorter passphrase generated from a large dictionary; a
| good one can be obtained from 1password:
|
| https://1password.com/txt/agwordlist.txt
|
| https://1password.com/password-generator
|
| or a longer passphrase from a short dictionary including
| only the most common words, like the EFF one:
|
| https://www.eff.org/dice
|
| https://secure.research.vt.edu/diceware/#eff
|
| I don't use either generator, preferring a local command:
| $ shuf --random-source /dev/urandom --head-count 5
| ~/.local/share/words | paste --serial
| --delimiters -
|
| wrapped in a small helper script with desktop
| notifications and copy-to-clipboard.
| wyager wrote:
| A lot of sites do this, annoyingly. I hate when my internet
| experience is degraded because the bottom pentile of users
| can't figure out how to do something.
| archerx wrote:
| Yes, why must the majority suffer because a few dumb dumbs
| can't remember their passwords? We need to subsidizing
| stupidity or else we will get more stupidity.
| archerx wrote:
| I hate this with a passion and many sites use it like anthropic
| and clipdrop, I stopped buying credits on Clipdrop because
| logging in was so annoying. My email is on my phone and I want
| to access the site on my laptop. This adds so much friction and
| turns a 5 second task with one to two clicks into a longer than
| a minute task with many clicks. I emailed anthropic about this
| and they did added a login with google option but just let us
| use an email and password please.
| adastra22 wrote:
| Christ, login with Google? I don't have a Google account
| either. Why can't they just have a username/password like the
| rest of the world?
| Too wrote:
| At that point you might as well go all in on single sign on.
| 95% of all users are going to be on gmail, outlook or apple
| anyway. Better to have a "sign in with google" button rather
| than "send a link to your (g)mail". They can track you either
| way.
| lxgr wrote:
| Please have both. We don't need more forced centralization
| when it comes to authentication.
| wruza wrote:
| I love when sites do _only_ that and then fail to deliver an
| email within 30 seconds.
|
| _a message to your phone "click to authenticate login_
|
| Should be both code and a link (enter 1234 or click <url>),
| because it's not always the phone you're loggin in on.
| sensanaty wrote:
| I despise magic links. The rare few times I have to log back
| into Notion or Slack, I want to rip my hair out because of how
| annoying of a system it is.
|
| Please, for the love of god, just let me use my username/email
| and password. Have the magic link for the dummies that don't
| use a password manager if you have to, just let me do the
| username + password way.
| adastra22 wrote:
| I don't have access to my email on the computer in which I am
| trying to login to your web service.
| mplewis wrote:
| Why not?
| fmeyer wrote:
| Identity is tricky. Proving who you are depends on a certain
| level of trust. Whether it's through email, devices, phones, or,
| in more advanced settings, some sort of digital certificate; you
| won't have much options.
|
| Unless you're in Germany using a service provided by the Vogons,
| you might end up getting a letter containing an activation PIN
| via snail mail or worst having to visit the post office to show
| your passport.
| gmuslera wrote:
| The second component of this, for people that doesn't care to do
| good track of their passwords, is that their email passwords are
| usually memorable in the wrong way. So both your mail and all the
| dependent services are all held together with the same weak clip.
|
| Double factor improved a bit this, or at least made it harder to
| break into this to some of the players, and simplified the
| process for some others.
| Ekaros wrote:
| Email passwords is interesting one. As my feeling with
| something like gmail is that you insert it approximately once
| or twice per device... Which leads to weird dynamic that you
| have to recall it way too rarely for actually to remember it
| properly...
| lelanthran wrote:
| > The second component of this, for people that doesn't care to
| do good track of their passwords, is that their email passwords
| are usually memorable in the wrong way. So both your mail and
| all the dependent services are all held together with the same
| weak clip.
|
| The point is that _they are already tied together_ because most
| sites allow password reset (or account recovery) via email.
|
| It doesn't matter how securely your sign-on is designed, what
| identification token you are using (username, biometrics), what
| authentication mechanism is in place (passwords, MFA, yubikey,
| etc) if all an attacker has to do is type in the targets email
| and click 'forgot password'.
|
| If your site allows password resets or account recovery via
| email, then the users account is still only as secure as their
| email password _anyway_. Adding yubikeys, MFA, authenticator
| apps, etc into the mix doesn 't move the security needle a
| single bit at all.
| robertlagrant wrote:
| The problem is just that despite all the advantages it would
| bring, people won't pay for auth as a service, where your
| identity is tied to accounts outside of an email address, and you
| (say) get a browser/phone notification to log in when you log in
| with MyAuthProvider and it's quick. They'd rather go through the
| email route, which is the same thing but slower and goes via
| Google.
| jt2190 wrote:
| I swear the McDonald's app for the U.S. works like this on
| purpose. I'm prompted for my email then thus send me a link. They
| never ask me to set up a password.
| EasyMark wrote:
| I don't see any business who wants to stay in business blocking
| gmail or outlook.com or yahoo or proton mail
| tqi wrote:
| > When I ask people why they do this, they either don't have an
| answer, or respond with "huh, I never thought about why". And
| that's interesting to me.
|
| I do this because I don't care enough about the particular
| account or use it frequently enough to manage put more effort
| into it.
| aucisson_masque wrote:
| Exactly, that should be obvious but it's just that they don't
| care enough.
|
| My mother used to do that, until I teach her about bitwarden
| and it has completely changed her thought process. It's just
| that having to remember every password is impossible and they
| don't know about password manager.
| MrGilbert wrote:
| Interestingly enough, that is the login flow Figma is using with
| my account. I provide my email address, and get an email that
| contains a linkt to log me in.
|
| I remember having seen this idea at other places before. I don't
| really like it, because for me, using a password manager makes
| everything already quite convenient.
| lelanthran wrote:
| > I don't really like it, because for me, using a password
| manager makes everything already quite convenient.
|
| How many people do you think use password managers? 1 in a 100?
| 1 in a thousand? Looking at the user counts for all the major
| password managers combined, the number looks more like 1 in a
| few dozen million.
|
| We're a demographic that is smaller than the demographic of
| blind users. As a group, we're _not even_ a rounding error. It
| makes no sense to optimise our group 's workflow when the
| resources could be diverted towards making a better product.
|
| After all, it's not like they lock out password-manager users
| completely.
| al_borland wrote:
| I've seen sites that cut out the forgotten password step, or
| passwords entirely... email is the authentication.
|
| 1. Type in email address
|
| 2. Get sent and email with code
|
| 3. Enter code to login
|
| While I can understand why someone might do this, as someone with
| multiple emails I kind of hate it. I had to add it to my password
| manager with the email and a note, so I remember which one to use
| and it's not missing a password.
| seanthemon wrote:
| Or maybe password managers need to catch up with this newly
| forming flow
| abdullahkhalids wrote:
| Keepassxc (and its browser extension) can do this easily. You
| just have to one time define that the website only takes a
| username field. After that it will autofill the correct email
| in the field.
| wpm wrote:
| Perhaps, a password manager managed email address used solely
| for these stupid links and codes.
|
| Why email then? Why not some other, better protocol?
|
| Why not just use a TOTP at that point?
| al_borland wrote:
| > Why not just use a TOTP at that point?
|
| Friction. When the username is an email address, 100% of
| people logging in have an email address. Telling someone
| they need to setup TOTP, especially if they have never done
| so before, is going to be a bridge too far for something
| they may only use once or twice.
|
| One site I remember using this email code login was a small
| online store. If I was prompted to setup TOTP to buy
| something, I would have probably not bought anything. If my
| mom was prompted for that, she'd end up calling me, and I'd
| have to try to walk her through the whole thing... then I'd
| keep getting calls the next 5 times she's had to login.
|
| If the site gives directions on what to do, they will
| probably only be written targeting a single authenticator
| app. For people who don't yet know that the apps are
| generic (in most cases), this can lead to a user having 3
| sites setup in 3 different apps. It can become a mess very
| quickly.
| archerx wrote:
| Or this stupid flow needs to die.
| EasyMark wrote:
| I get this a lot because I use Mullvad 99%of the time. I hate
| it, but I put up with it because I don't have much choice. I
| guess they're flagging the "popular" ip address that I'm using.
| al_borland wrote:
| If it's only doing it because of your VPN, I think I'm
| talking about something else.
|
| This isn't where you put in a username and password, then get
| an email code prompt because something looks off.
|
| In the case I'm talking about, the user has no password. This
| is just the way it is, VPN or not.
| hnick wrote:
| We offered it on a site with a "guest login" where people
| redeem vouchers but might not want to make an account. So I
| think that's one valid use case. We need to associate the
| voucher with the email, so we need to ensure they own it by
| clicking the link, in case of support hassles down the line for
| lost vouchers. And if they make the account later they can see
| their old ones from before.
| esafak wrote:
| It means the site doesn't store your password, so you have less
| to worry about.
| al_borland wrote:
| That's the reason I can understand why they do it. It's less
| information they are holding on to, and they effectively
| outsource authentication to the email provider.
| lelanthran wrote:
| > I've seen sites that cut out the forgotten password step, or
| passwords entirely... email is the authentication.
|
| I do this with a B2B SaaS: an individual user would log in
| maybe once of twice every six months. Have passwordless logins
| means:
|
| 1. No added pressure on the user to remember a password for a
| service they use rarely.
|
| 2. Easier onboarding for companies, as they upload a CSV of all
| their users and their users can get to work immediately without
| being prompted to create a password, double-check it, confirm
| it, adhere to the rules, etc.
|
| I don't like using links in emails, as they get 'clicked' by
| many phone apps when previewing, by corporate virus scanners,
| etc.
| archerx wrote:
| I have stopped giving websites money because the friction of
| using magic links was too much and I found alternatives that
| didn't involve such a dumb login system.
|
| My theory is if you can't make a proper login system you're
| skills probably aren't good enough to deliver on what you're
| promising. Magic links have turned from an annoyance to a
| filter for me.
| lbriner wrote:
| "My theory is if you can't make a proper login system you're
| skills probably aren't good enough to deliver on what you're
| promising."
|
| Using that logic, I wouldn't trust most websites I visit.
| Even FAANG companies with their billions can't do certain
| things properly. Even something reallly basic like focus the
| 2FA box when you ask for the code, don't make me have to
| click on it! Don't stop people pasting passwords, don't limit
| how long the password can be (within reason) don't say they
| can't use arbitrary characters like a - because "SQL
| Injection" and don't invent riduculous hurdles like adding
| random digits from a secret word as well as your password. If
| you are going to do that, just ask for two passwords or tell
| people if you choose stupid passwords, you will be hacked!
|
| I like the password strength meter that doesn't block
| passwords that it has mistakenly decided are weak (20 random
| alpnanumerics) but instead estimates how quickly it could be
| hacked. People don't understand entropy but might understand
| "hacked in 5 minutes", they also don't want to be told that
| your password has to be at least 100 characters long with
| uppers, lowers, numbers, specials, klingon etc. If your
| system is that susceptible you are doing it wrong.
| archerx wrote:
| Don't look at FAANG as examples, they are usually the
| leaders in modern day bad UX.
| darajava wrote:
| I would say a huge proportion of non-technical consumers do not
| use a password manager. By only offering password signup and
| not magic links/codes, I am probably making life harder for the
| vast majority of consumers.
|
| Even if I offer both options, I would guess that I'd see more
| drop off during my signup flow by asking for a password as well
| as verifying their email. Not to mention the code is way
| simpler without dealing with passwords and multiple login flows
| for email.
| miki123211 wrote:
| I'm surprised we don't have a standardized, cross-browser,
| simple, email-based authentication system.
|
| Basically something like this:
|
| 1. Website generates random string as challenge, sends to
| Browser, invokes API via JS on the client side.
|
| 2. Browser asks user to select the email to use, allows adding a
| new one.
|
| 3. Browser sends its auth token and challenge string to Browser
| Maker, Browser Maker verifies that the auth string is valid,
| signs email address and challenge with its public key, transmits
| signature back to Browser.
|
| 4. Browser sends data back to Website, Website verifies that the
| signature matches and that Vendor is trusted, lets user in.
|
| As an extra precaution against Vendor being hacked, Email
| providers could implement support for the system. Compliant
| providers would handle the email verification flow themselves,
| informing Browser maker when done and sending an extra
| certificate. Websites would then refuse to accept any logins
| where Email Provider indicated support (via DNS records) but its
| certificate wasn't included.
|
| This would also make the system usable in small (and therefore
| untrusted) browsers, as long as the email provider implemented
| support.
|
| It would even improve privacy, Browser Maker and Email Provider
| would only ever see the random challenge string, which would make
| it impossible to track the websites you visit.
|
| THe idea isn't hard to implement, we've had the tech to do it
| since the 90's (US restrictions on crypto notwithstanding). What
| we have instead is a mess of passwords that nobody can remember
| and proprietary authentication flows with horrible developer
| experience, terrible privacy issues and spotty website support.
| motoboi wrote:
| Well you kinda reinvented passkeys.
| eaglemfo wrote:
| I wish sites would acknowledge the need for a nerd mode that gets
| rid of all the stuff that annoys nerds and is essentially
| password or lockout, no resets. Enable reset methods or 2fa at
| your own whim.
|
| For the rest you can do weird stuff that doesn't work on nerds.
| monus wrote:
| Well, yeah, "magic link" is a thing and one of the easiest form
| of authentication supported by many providers, like Supabase,
| Vercel and libraries like Next Auth.
|
| Another great side effect is that your backend doesn't have to
| store user passwords which means removal of a lot of compliance
| headaches.
| archerx wrote:
| You should never store passwords in any case. Hash + Salt.
| montroser wrote:
| I am one of those people who always clicks "forgot password", and
| sorry but it's actually fine. I type a long, completely nonsense
| sequence of words and characters for my new password, then ctrl-c
| to copy, then log in with that password, and then promptly forget
| it.
|
| It cannot be more secure to store it in a password manager than
| not to store it at all. The email recovery path exists in either
| case, so that part is a wash.
| 6510 wrote:
| you may lose the email
| dw_arthur wrote:
| I only do this on websites where I don't care if I lose the
| account. I use a password manager for anything that is
| critical.
| OptionOfT wrote:
| When you sign in at Home Depot, it defaults to sending you an
| email that you can click to sign in. And I absolutely hate it.
|
| There is a tiny link at the bottom that allows you to sign with a
| password, which I prefer.
| namtab00 wrote:
| medium.com too... I hate it
| PaulHoule wrote:
| Any strong 2 factor authentication without the kind of high touch
| processes that a bank can afford is a corporate suicide pact. 10%
| or so of your users will be permanently locked out each year and
| once you get past the early explosive early growth phase that
| turns into a near steady state instead you get radioactive decay.
| throwaway14356 wrote:
| you could make a password optional and just login from email.
|
| I will share this great innovation of mine:
|
| The location.hash is not send to the server. You can javascript
| it into a POST rather than a GET.
| mozzieman wrote:
| A physical key you have put in your computer and store on your
| keychain.
| deisteve wrote:
| not sure i get what this article's point is
|
| its the go to pattern because its the most resilient and
| intuitive
|
| we've been using emails for a long time and it makes sense that
| it became the go to authentication method
| 3np wrote:
| This is actually a really good use-case for PGP. Opt-in use to
| upload the pubkey and, if provided, encrypt automated e-mails
| like auth links and password reset.
|
| Facebook supported this for years, not sure why they recently
| deprecated it.
| melody_calling wrote:
| I hadn't realised until reading this, that I use this exact
| method for Best Buy.
|
| Not intentionally though - I have my password stored in
| 1Password, so I know it's correct, yet every time I try to
| purchase something through bestbuy.com I trip some sort of ATO
| protection that falsely claims my password is invalid.
|
| I'm entirely willing to believe it's something on my side (ad
| blocker, local DNS blacklisting, etc.) but after a certain number
| of occurrances, you get bored trying to debug the problem and
| just follow the path of least resistance.
| dqv wrote:
| > Not intentionally though - I have my password stored in
| 1Password, so I know it's correct, yet every time I try to
| purchase something through bestbuy.com I trip some sort of ATO
| protection that falsely claims my password is invalid.
|
| Are you sure it's not a maxlength mismatch? It is _very_ common
| to have the "change password" field to have a different (or
| no) maxlength and then have the login page have a _different_
| maxlength. So you change your password to some 60 character
| password, then you log in where the maxlength is only 40
| characters... wrong password! I actually have a policy now of
| having the maxlength stored in application config so it
| propagates to all password fields in my apps.
|
| Edit: Just checked and yes there is a length mismatch (form to
| set password has maxlength of 54, but login page has no
| maxlength set). So if your password length is > 54 and
| 1Password doesn't automatically cut the password it stores to
| 54 characters or fewer, you won't be able to log in.
| coldblues wrote:
| I know a few sites, one of them being Spotify, that will lock
| your account based on "suspicious activity", lie that your
| password is invalid, and force you to reset your password.
| packetlost wrote:
| With email being _the_ source of identity on the internet, it 's
| really unfortunate that the standards have largely lagged heavily
| behind when it comes to stronger authentication algorithms. Why
| is SMTP still plaintext on port 25 for MTA<->MTA? Why is STARTTLS
| really the best we can do? Why do we not support 2FA or mTLS or
| passkeys or any one of the other modern authentication mechanisms
| or IMAP4, SMTP, etc.. ProtonMail is _ok_ but the hoops they have
| to jump through to get their stuff working is obnoxious.
| gunapologist99 wrote:
| And why, in 2024, is _requiring_ any encryption at all a
| violation of RFC 5321, thus making any MITM literally a trivial
| and impossible to defeat downgrade attack?
| 8organicbits wrote:
| Worth looking at MTA-STS. I think DANE is on the way out, but
| it looked promising for a while.
| charles_f wrote:
| The thing is, the moment some service allows you to recover your
| password through email, this becomes a legitimate pattern. As
| long as the throwaway password is reasonably complex, the service
| becomes as secure as email can be (which is, imperfect)
| gunapologist99 wrote:
| For seldom used (or cared about) accounts, this is pretty low
| friction, and most of those will keep you logged in for an
| extended period of time.
|
| From a perspective of one of these people, why even bother with
| trying to remembering a login or dealing with tools you don't
| have, like if you don't even have a password manager or know that
| they exist.
|
| From a systems and security perspective, it could be worse. They
| could be reusing passwords.
| csomar wrote:
| > and whether we can take advantage of people's tendencies
| towards learned behaviour like this.
|
| Isn't that what some services are doing already? There is no
| password in Notion, you just enter your email and the password is
| sent to your email address.
|
| Login with Email is like a primitive "Login with Google" where
| the user himself transfer the authentication token. It's still
| better in one area: no lockdown to a particular cloud provider.
| However, it doesn't address security, it just concentrate it in
| one place. Lose your email and now you have a much bigger
| problem.
| 8organicbits wrote:
| User researchers are great at making these kinds of discoveries.
| The basic idea is that you've got to actually watch a user when
| they use your site, ask some questions about what they are seeing
| and thinking.
| runako wrote:
| Disclaimer: I loathe this pattern & hope something like WebAuthn
| prevails instead.
|
| That said, if folks are going to adopt this as a primary flow,
| perhaps email clients need to build in support. For OS providers
| like Apple, maybe this means less emphasis on the easy Passkey
| method and more on fixing the finicky email login flow that sites
| use instead?
|
| What would a good email login flow look like? What is the
| "password manager" equivalent in a magic link world? On something
| like iOS or MacOS with Safari, could the browser/app & email
| client communicate to make the login seamless (after the email
| delay)?
|
| Are new OS-level APIs needed for native apps such that they don't
| require switching apps to login? (This is a truly awful
| workflow.)
|
| Should sites stop making people register with passwords at all?
| What is the point of passwords when auth is primarily handled
| through magic links?
| archerx wrote:
| A good email login flow is where I put my email and then my
| password then click login. Anything else is pure wankery
| pflenker wrote:
| I used to follow this process for many of my logins (the less
| critical ones) before password managers were mainstream, and it
| was a conscious decision to do so.
|
| It's more secure than a) reusing an existing password everywhere
| and b) setting a trivial password that _just_ passes the site's
| password requirements.
|
| You can't expect me to memorize all passwords for all different
| logins, especially the ones for less important sites, and
| especially if these sites impose their ridiculous password
| restrictions on me.
| ramijames wrote:
| This is why I've been relying on magic links via email as a sign-
| in/up method for my applications. Users will either default to
| oAuth OR they will use some generic email/password combo. The
| magic-link works for both sets of users and ensures that they
| always have instant access without having to manage yet another
| password.
| sgoto wrote:
| At this point, wouldn't "email authentication" simply be OpenID?
| gloosx wrote:
| >why they do this
|
| There is always a simple answer to such question, and it's
| usually about some inconvenience the service provider decided to
| set-up for the user. In this particular case I think the answer
| is obvious: email provider usually have a session which never
| really ends, and just sits there logged in unless the browser
| cache is wiped.
|
| Make your service auth token to live for the same time as
| Gmail's, and as an alternative give users an ability to just
| login with OTP every time, but stop these unholy 12 hrs time-to-
| live auth token practices - your users will never log-in via
| password restore again.
| lbriner wrote:
| I think this is closer to hinting at the truth. GMail and
| Cloudflare (and many other "high security orgs) have very long
| auth sessions. Why? Because the chance of somebody getting onto
| the PC of someone who uses these systems and hasn't logged out
| is actually really low. Most hacks are remote and based on weak
| passwords.
|
| Unfortunately, we lack the consistent language to measure risk
| and decide "do I really need 2FA on this site?" "Is 30 minutes
| a reasonable session time?". I think as long as someone has an
| up-to-date virus checker, most would rather stay logged in to
| stuff. Anyone ever been asked to delete all cookies to fix a
| problem on a site? My answer is always to "go fish".
|
| I remember somebody saying before, "it's your account, if you
| want to stay logged in and risk a hack, it's your risk not the
| company running the service". I believe that more and more. If
| your laptop is logged in and someone deletes all your EC2
| instances, that's on you, not AWS for not logging you out
| sooner. They _could_ but why should they? Piss off 1M users to
| try and protect 1 person who is too careless?
| RockRobotRock wrote:
| If I launched a startup I would absolutely use magic links for
| auth. Minimum friction for users.
|
| As a user, I hate it.
| treflop wrote:
| It's because password sucks.
|
| You're supposed to not reuse passwords, but then you don't
| remember passwords.
|
| So you use a password manager. Until more recently when phones
| and computers came with built-in password managers, no normal
| person was going to download a password manager.
|
| But even when you use a password manager, sometimes it doesn't
| recognize the form fields. Or it doesn't show it because the
| domain is different. Sometimes it doesn't save a new login. The
| website has no direct awareness of the password manager so it's
| hit and miss.
|
| So we created passkeys. Except it's also hit and miss. Some sites
| only sometimes ask for them. No site explains what they are. Some
| sites ask for you to login with a passkey, which you wouldn't
| have yet, but then don't ask you to setup the passkey after
| logging in with a password, so you never set up a passkey.
|
| Overall authentication is a disaster and my very fiery take is
| overly technical people who are out of touch with normal people
| design authentication.
| wruza wrote:
| _When I ask people why they do this, they either don't have an
| answer, or respond with "huh, I never thought about why". And
| that's interesting to me._
|
| Is that a storytelling touch? Users aren't dumb or unreflective,
| they know that they have nowhere to store their passwords, that's
| why. Even if they aware of password managers, they can work on a
| shared cloud pc, so switching PM accounts would be a bigger
| hassle.
|
| _How do you decide that using "I forgot my password" as
| authentication makes sense to you?_
|
| A "trash caregory" site that didn't bother to tag its
| username/password/etc elements as password-saveable, thus my PM
| didn't ask to save the password. That is usually enough to not
| give af about saving it. Happens more often than you might think.
| antimemetics wrote:
| > work on a shared cloud pc
|
| That sounds insane, is that actually happening in practice?
| What is the point?
| wodenokoto wrote:
| I use this for webpages that have weird requirements for
| passwords. I can never remember what I enter on those so ...
| obscuretone wrote:
| A lot of sites are moving to OTP instead of passwords now.
|
| Make Auth Gmail's problem.
|
| It's not a horrible idea in theory.
| soerxpso wrote:
| Their motivation is immediately clear to me. If you use "I forgot
| my password" you don't have to remember a password. And it
| doesn't even make your account less secure, since that pathway
| was going to be available to attackers regardless. I've seen
| websites that make that their default flow, arguing (implicitly)
| that having passwords at all is pointless when you can just email
| someone a login button, skipping a step.
|
| Personally, I hate it. I don't trust my email, hate that it's a
| single point of failure for dozens of accounts (it's not "2FA" if
| the second factor is the only one I need), and I'd prefer to log
| in with a password without any option to reset it. But alas.
| oerdier wrote:
| > it's not "2FA" if the second factor is the only one I need
|
| It will be 2FA again if you protect your email with 2FA
| SPBS wrote:
| Wow, that's awful. So they abuse "forgot your password" as a
| login method, with the added obstacle of having to come up with a
| random password every time. And they don't see any problem with
| it. My hunch is that all these people are _very_ non-technical
| users.
| EnigmaFlare wrote:
| I do that for some sites. It's the initial effort required to
| set everything up that's the obstacle. This kind of behavior is
| taking the easiest route at every step instead of investing
| time into making the future easier. I stopped using a password
| manager after it got hacked and haven't bothered setting up a
| new one.
|
| The most annoying sites require you to confirm your throwaway
| password or log in again using it, and can't copy from the
| password field, so you can't just spam the keyboard and have to
| type it into notepad then copy and paste a few times before
| discarding it. This is stupidly inconvenient to do all the time
| but the alternative is more inconvenient to do once -
| researching which password manager is currently safe, finding
| it, installing it, writing down your master password somewhere
| really safe, etc. Then keeping on top of the news for the rest
| of your life to see if your password manager is going down the
| gurgler or been hacked. Also, will my passwords be available
| when I travel to a country with restricted internet? Who knows.
| Can I export my passwords to any other password manager or a
| text file if I need migrate? That's part of the research needed
| to even get started using a password manager.
| rmrfchik wrote:
| And then you are blocked by google.
| tsing wrote:
| The most common login process in China:
|
| 1. Enter phone number to received a six digits code 2. Enter the
| code
| PeterStuer wrote:
| This one is easy:
|
| First of all, 'real' people do not use password managers, and
| they feel a slight suspicion towards the browser 'remember
| password' dialog so rhey decline.
|
| They also have some boomer uncle that told them 'never to write
| down passwords' for the days where people post-it them to the
| monitor in shared office spaces.
|
| They also know 'not to reuse passwords' because if one site gets
| powned your password for everything is out there.
|
| So they develop a heuristic for mutating their 'master' password
| depending on the site or app, only to get thwarted by insane (not
| an exaggeration) password requirement rules.
|
| So they have to deviate from their heuristic, and will not
| remember the password they had to make up on the spot next time
| around, so a reset password email it is.
|
| Bonus: they make up a new password, omly to be informed they can
| not reuse a previously used password. XD
| ChrisMarshallNY wrote:
| Login and authentication are a really big deal, and represent
| some of the most complex code, in one of my apps.
|
| In fact, I just made a release last night, to try ensuring that
| we reduce the number of bad emails (I thought I could get away
| with eschewing the traditional "confirm email" thing --I was
| wrong. There's a reason the classics are popular).
|
| Since it is an iOS app, I can implement Sign in/up with Apple,
| which helps a lot.
|
| It's still a work in progress, though. I use the Keychain to
| store login info, with Face/Touch ID, to smooth the login
| process. Works fairly well.
| protocolture wrote:
| A few services are just bypassing passwords and emailing you one
| time codes these days and it isnt the worst idea for exactly this
| reason.
| lxgr wrote:
| I agree, but I strongly prefer the ones that allow both. I use
| a password manager, and a mandatory OTP email flow often annoys
| me enough that I think twice about logging in if it's not that
| urgent.
| thepra wrote:
| at least for my privacy conscious web apps I don't even expect
| email for login, just a username and password.
|
| And if people really want to enable password recovery then they
| add their email into their profile and that data point is only
| used for that.
|
| It might bother some, but I don't really want to require emails
| for privacy related services. My two cents.
| kookamamie wrote:
| > I think people can't answer why they do this because it's not a
| concious decision
|
| It's because that's simply the most convenient way of accessing
| the service. There are tens of services people use these days and
| passwords are seen as a nuisance. If there's an easier way of
| logging in, people will use it - no matter the security
| implications.
| thatjoeoverthr wrote:
| The idea that someone is going to invent and remember a password
| for every dumb service is not real, and when you build another
| password based authentication system, you are doing a kind of
| LARP.
|
| Passwords are used in one of two ways:
|
| 1. a password manager guarded by a single actual password
|
| 2. the same password repeated between services
|
| Practically every service offers e-mail recovery, so, in
| practice, your e-mail is your authentication.
|
| Personal e-mail accounts are rarely replaced, not shared, and
| aren't reused. You've probably had your personal e-mail longer
| than your phone number. I've had at least five phone numbers in
| the life time of my current e-mail address. Other people now have
| those numbers.
| bombcar wrote:
| Apple has made the incredibly annoying "you can't just enter
| your 1Password/keychain password, you have to dick around with
| email" process much nicer; at least when it can recognize the
| email/text and enter the code for you.
| bmitc wrote:
| Apple is the worst about this. The only option is that they
| send a message to an Apple device. I only have an iPad and
| not an iPhone or Macbook, so I often simply cannot log into
| my Apple account because they refuse to do anything else
| besides send it to an Apple device.
| 4ad wrote:
| Not true, you can use FIDO2 keys. You can even use SMS (but
| you shouldn't).
| bmitc wrote:
| Yes, it is true. There are indeed cases where you are not
| presented with SMS options.
|
| And I'm not going to purchase and carry around a hardware
| key just for the privilege of periodically logging into
| my Apple accounts.
|
| Maybe Apple shouldn't force you to own an Apple device to
| login to your accounts? They've been sued about this
| before and lost. If Microsoft did this, people would lose
| their minds.
| paulryanrogers wrote:
| There are also derived passwords, which are kind of a hybrid.
| Either as a pattern the human remembers or a manager that does
| the calculation per domain.
|
| I'd also add that forgot password features at least notify the
| address owner of every attempt. Password based logins don't
| always email on every login from a new location.
| bmitc wrote:
| In general, I really am disturbed that so many websites use my
| email and phone number for authentication. I use authenticator
| and password manager apps for a reason. Using my email and phone
| number is both unsafe and was never approved by me. They just
| started doing it. Further, there's no way to turn it off.
| will1james wrote:
| What are the other potential problems of the "email is
| authentication" pattern, under the following prescribed
| conditions? Maybe just these two?
|
| (Prescribed Conditions)
|
| - "Credential Recovery" complies with OWASP ASVS and is
| "adequately secure".
|
| - "Credential Recovery" is the "weakest link" of authentication.
| (Other authentication methods require TOTP, etc.)
|
| (Potential Problems)
|
| - The financial cost of sending emails. - my
| guess is that, since I could not find of news of this issue,
| these users are only a small percentage (hopeful not yet)
|
| - End-to-end response time for the "Credential Recovery"
| authentication process - my guess is that users
| who choose "Credential Recovery" authentication over
| other "happy-path" authentication are willing to wait, or
| are use to waiting.
|
| (Non-problems)
|
| - If the above conditions are specified, authentication security
| is not compromised.
|
| (Terms)
|
| - "Credential Recovery" as in OWASP ASVS V2.5 Credential
| Recovery, or "Self-service password reset" as in Wikipedia, or
| "forgot password" flow.
|
| https://en.wikipedia.org/w/index.php?title=Self-service_pass...
| https://owasp.org/www-project-application-security-verificat...
| https://github.com/OWASP/ASVS/raw/v4.0.3/4.0/OWASP%20Applica...
|
| - "adequately secure" as in NIST SP 800-160 Vol. 1 Rev. 1, 3.
| System Security Concepts, 3.2. The Concept of an Adequately
| Secure System.
|
| https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final
| https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
| fredsted wrote:
| For most people, doing stuff on computers is a matter of brute
| forcing it until kinda does what it's supposed to. Software is
| made by people who have an intricate understanding of how the
| underlying system works, but it's made _for_ people who don 't.
| When users get to a pattern that works, they stick with it. It's
| becoming even more common now that many schools are using tablets
| for education - they don't get a good feel for how a computer
| works. Most people don't think about it. It's just there, and
| they're used to things being broken, so what's a few extra
| clicks?
| overstay8930 wrote:
| > Software is made by people who have an intricate
| understanding of how the underlying system works
|
| Maybe 10% of software developers actually have an intricate
| understanding of what they do, in fact it is because developers
| don't really understand what they are doing is why regular
| people brute force horrible software.
| amelius wrote:
| How do you deal with the situation that you lost access to an
| email address (e.g. change of employer) and years later you want
| access to an account that turns out to be tied to that email
| address?
| lwansbrough wrote:
| We run a pretty unserious business. That is, our users use our
| accounts only out of convenience. The system we've settled on is
| this:
|
| 1. User enters email
|
| 2. We send a verification code to their email
|
| 3. User enters code, is signed in "indefinitely" (very, very long
| cookie)
|
| Whether or not they had an account before hand is irrelevant, we
| just register a new account if the email is new. The occasional
| user has multiple emails and sometimes creates a new account
| accidentally. This is an acceptable disadvantage as we've
| observed dramatic improvements in registration and sign in
| conversions.
|
| There is some risk analysis to do here on the code lifetime and
| cardinality (better yet, use a lockout mechanism.) If your
| service isn't particularly important, I recommend this strategy.
|
| Mail on iOS now supports this type of mechanism too (same as the
| Messages one-time code functionality) so it can be quite painless
| for some users as well.
| t0mas88 wrote:
| This is also (from the data that I have seen) by far the best
| approach to maximise ecommerce revenue.
|
| Don't force buyers into an account, just ask their details (the
| browser will autocomplete anyway). Send an email afterwards
| with a link to check their order status. Next order, ask for
| their email again.
|
| Any extra friction costs more in lost revenue than the benefits
| of having "signed up" users.
| cmeacham98 wrote:
| Wouldn't the best approach be not to ask for an email at all
| (or only optionally for receipt)?
| sq_ wrote:
| I would imagine that plenty of users these days wouldn't
| bother to save their order details on the grounds that "oh,
| I'll get a notification with those".
|
| Personally, I appreciate getting an email with details and
| a link for tracking. It does get annoying when it turns
| into low-grade spam, though.
| WA wrote:
| I run a small B2C app. Users sign up with their email address
| only, a password field isn't even present. This creates the
| account and logs in the user "indefinitely" on this device. If
| they ever need to login on another device, they can request a
| new password. This way, this removes a) signup friction und b)
| weak passwords, because most people never need to login on
| another device anyways.
| eddd-ddde wrote:
| I like the concept but at the same time I hate having to open
| my email to login to a site.
|
| I already have a password manager. I rather just generate a
| password on one go.
| lwansbrough wrote:
| I agree it's inferior to a password manager but I think
| passkeys will usurp the role of password managers in the
| long term, and for everyone else who won't use either, a
| simple email is an easy ask -- better than having them go
| through password reset every time they use the site.
| WA wrote:
| It's "temporary". You can set a password later and use it
| to login with email + password and store it in your
| password manager. Only the initial signup and the first
| login on a new device will require the "reset password"
| workflow. Imho, that's the best of both worlds.
| rollcat wrote:
| Second this, used this approach on a tiny CRUD app that was
| essentially a single form. The amount of support requests
| (approx. zero) throughout the campaign was absolutely worth it.
| brainzap wrote:
| How do you do very long cookie? I thought safari deletes them
| anyway after a certain time.
| lwansbrough wrote:
| I mean, it doesn't really matter. Just do it as long as it
| works and when it stops working they can sign in again. The
| point is to quit hassling your users in the name of
| "security" if you're not a security critical application.
| YMMV.
| ftlio wrote:
| This is how I've implemented login several times now, and it
| comes from repeatedly having to undo a ton of assumptions about
| what a User Account is when attempting to modify a funnel to
| just actually work how people want it to on both sides of the
| equation.
|
| Unless you're operating in an anonymity preserving space, you
| can just do this and choose to integrate with passkey later.
|
| The main disadvantage of this method is that you have to think
| about managing multiple users for an account sooner than you
| normally would, since sharing a password is no longer possible.
| I can't think of a funnel or UX that isn't ultimately improved
| by conscious effort here.
|
| The other is of course that your security becomes limited by
| the weighted average of security of your users' email
| providers, which will generally be better than you need.
| Passwords can then be your second factor here, when you finally
| need them, or you can use some other factor yet again. In B2B
| you can jump straight to SAML or OIDC connections.
|
| In B2B or D2C contexts this has always just worked and the edge
| cases are generally worth solving for the benefits to
| acquisition.
| osigurdson wrote:
| This is essentially the same as "sign in with Google / Facebook /
| etc." with added pain for the user.
| coding123 wrote:
| I think it should be entirely oauth. no password needed
| mplewis wrote:
| If passwordless sign in is good enough for Booking.com, it's
| certainly good enough for any app that I ship.
| internet101010 wrote:
| Sometimes email is the best way. Like if you are constantly
| posting files to third-party file hosting services (Box, Dropbox,
| etc.) that are not tied to AD of the recipient you have to have a
| way to ensure that only people _currently_ working at the company
| can access the content. SMS and TOTP do not solve this problem in
| the same way that email does.
___________________________________________________________________
(page generated 2024-09-08 23:01 UTC)