[HN Gopher] Why even let users set their own passwords?
___________________________________________________________________
Why even let users set their own passwords?
Author : hlandau
Score : 214 points
Date : 2023-07-22 13:36 UTC (9 hours ago)
(HTM) web link (www.devever.net)
(TXT) w3m dump (www.devever.net)
| AlbertCory wrote:
| This is the regular reminder that you _can_ create your own
| password, provided it 's created via a secret which only you
| would understand. Then you can store the secret safely.
|
| It can't be your wife's name, or your birthday, your kids' names,
| car license, or anything which someone could research.
|
| We've had this discussion before.
| wizofaus wrote:
| I've often been struck by the fact that often login via password
| requires 2FA but password reset doesn't (unless of course it
| works via email that itself requires 2FA to log into). At least
| some authentication systems now never bother with persistent
| passwords at all and simply rely on you providing a code sent in
| each login to your email (or occasionally still via SMS - though
| that's rapidly falling out of favour, at least partly because in
| many countries SIM-swapping a significant problem, though the
| bigger problem I've observed is potential delays of several
| minutes for codes to arrive). But I certainly wouldn't want that
| for systems I have to log in into multiple times a day - a
| combination of browser-auto-filled password, plus use of basic
| browser fingerprinting techniques to avoid having to require 2FA
| every time seems to work okay though it seems ridiculous to me
| that just wanting to reply to a group chat message would require
| the same level of verification as downloading
| source/documentation etc.
|
| A compromise between allowing users full control over their
| passwords and none at all would be generating a list of permitted
| alternatives and having them pick one. What I'd then like to see
| is that early on you are required to supply it quite frequently,
| giving you a chance to commit it to memory, but then allow having
| the browser store it or session cookies with longer lifetimes be
| used. But I've yet to come across a login system where ensuring
| the user learns their password and doesn't forget it was a
| priority at all.
| CyberRage wrote:
| There is one incorrect statemement that really bothered me
|
| TOTP and passwords are not the 'similar' because TOTP is a secret
| generated from the 'key' and is only valid for a short time
| period
|
| this make usage of that secret vastly more challenging for
| attackers, especially at scale.
|
| I've seen real attacks where passwords are stolen, it is
| impossible to keep track of that. However for TOTP since the
| attacker has to login NOW, you can very easily detect anomalies
| of a new IP addr with many successful logins for different
| accounts
|
| Or to put it differently, when you capture a password it is
| always valid credential but for TOTP, it requires more advanced
| infrastructure(automatic logins, save tokens)
|
| and even then the token will eventually expire, with password you
| can generate infinite tokens
| radicality wrote:
| My understanding of the post was the the author means that from
| the point of view of "authenticate this user", the TOTP
| _key/seed_ is quite similar to a password, which I would agree
| with. Especially if you're storing both in your password
| manager like the OP.
| CyberRage wrote:
| It is not because:
|
| 1. TOTP is time based, after 30 seconds it means absolutely
| nothing, you cannot recreate the 'secret key' from that
| number
|
| 2. with TOTP everything is well-known. TOTP will usually
| generate a 6 digit 'secret', this makes managing it very
| predictable:
|
| 6 digits = 1,000,000 options(including all zeros) we can
| easily calculate a good security margin
|
| like: 5 attempt - 5/1,000,000 = 0.000005% chance of success
| Very predictable security margin
|
| for passwords it's a huge unknown, it entirely depends on the
| user password quality
| krupan wrote:
| While you are technically correct, you are missing the
| whole point of the blog post
| kortex wrote:
| > the TOTP _key/seed_ is quite similar to a password
|
| It's not though. The whole point is the secret moves _once_ ,
| from server to client (ignoring user exports and whatnot).
| Pass(word|key)s are basic authentication, and so have to be
| transmitted with every request. That's a huge difference in
| surface area. Also they are guaranteed to be high entropy,
| unlike user-picked passwords with no filter.
| teddyh wrote:
| There are some who claim that people will demand a way to set
| their own passwords. This has not been my experience. At work, we
| have been setting random secure passwords for e-mail and web site
| customers for more than 10 years (the practice was in place
| before I started, so I can't give an exact time). Very
| occasionally, a customer asks to change a password and give them
| a new one, which we gladly do.
| paddw wrote:
| Because for the average user it is still significantly easier to
| download some app to use in combination with a password they have
| a mnemonic for rather than having to figure out their own system
| for storing and retrieving long tokens in a reliable way. Also,
| most users are not obsessively clearing out their cache, so
| device recognition based password flows work seamlessly a lot of
| the time.
| paulryanrogers wrote:
| Average users are also unlikely to enter passwords often enough
| for them to remember or develop mnemonics. For them forgot
| password emails are the defacto login method.
| tomjen3 wrote:
| The system they will choose will be to get a new token by
| logining in with their email.
|
| It will effectively be the same as those places that send you a
| login email after you have entered your password for security
| or harrashment (looking at you, Zoom).
| CrampusDestrus wrote:
| Here's why: the world is not able bodied Americans, so let us
| decide what password is best for us through _our_ input methods
| kstrauser wrote:
| That's an interesting POV. Thanks!
| simias wrote:
| Can you specify what in practice could be an issue with a
| "forced" password? Are some characters harder to input than
| others or is it a different problem?
|
| For the non-American aspect, it's extremely common for websites
| to force ASCII today (either explicitly, or because using
| anything else breaks in various unexpected ways) anyway, I
| doubt that any internet user around the globe will have an
| issue with that. That boat has sailed in the 90s.
| CrampusDestrus wrote:
| in my locale's keyboard, curly brackets and the dollar sign
| are not obvious to input. they require an additional combo of
| keys that most people have no idea about.
| simias wrote:
| Yeah that's a good point, I definitely that automatically
| generated passwords should be limited to alnum, using
| symbols is asking for trouble.
| kwhitefoot wrote:
| In what character set?
| summerisle wrote:
| There are better solutions perhaps, but this article (as many
| others here have pointed out) reads as if it were written by
| someone that just "graduated" from a security bootcamp and thinks
| that they have some earth-shattering revelation to share.
| throwaway737248 wrote:
| [dead]
| danparsonson wrote:
| > A given website might obnoxiously refuse to trust in my ability
| to set a secure password, assume the 24-character randomly
| generated password I keep in my password safe is insecure, and
| demand I complete an email challenge every time I login
|
| ...because it's easier and cheaper to apply one rule for every
| user and you're an outlier. Most users don't have password safes
| - they have passwords like 'Messi123' that they use across
| multiple sites, and therefore benefit from a second factor since
| their first factor is more or less non-existent.
| samwillis wrote:
| We probably will stop one day, but that day isn't yet for many
| services. There are people who would be unable to use those
| services if that can't set the password to either the same or a
| variant of one they always use.
|
| In the tech wold we often forget that there is a wide disparity
| in people's ability to use tech. Take my father, there is no way
| he could use a password manager, or two factor, it's just never
| going to happen. He has a notebook of passwords, that's how he
| works and he won't change.
|
| We cannot change everyones behaviour, no matter how much it would
| be better for them. That's a very well learnt lesson, over and
| over.
|
| The world in 30 years time will be very different, the eldest
| generations will have grown up with passwords and the internet.
| Many will have been using password managers, 2 factor, other
| authentication systems and devices for much of their lives. It's
| going to be a slow, trickle down change, from "high tech"
| services down to everyday sites and systems.
| _Algernon_ wrote:
| A randomly generated password _is not_ incompatible with the
| notebook approach...
| samwillis wrote:
| It is when they are all a variant of each other. I can't
| imagine him successfully writing down a bunch of none
| alphanumeric characters and not giving up.
| orev wrote:
| A randomly generated pass-phrase can be both secure and
| easy to remember/write down.
| cubefox wrote:
| It can, but it's very unlikely. Most randomly generated
| data doesn't have a memorable structure.
| orev wrote:
| Please pay attention to the use of pass-PHRASE. Pass-
| phrases are well understood at this point as far as what
| they are and how to generate them securely. A key point
| is that they're much longer so have plenty of entropy to
| resist cracking attempts.
| janalsncm wrote:
| The article is discussing the merits of letting users
| generate their own passwords at all. So unless you can
| guarantee the website will generate nice pass phrases,
| you'll have to account for weird characters too.
| ewi_ wrote:
| A password manager can generate nice passphrases. Really,
| generating a nice and secure passphrase is no different
| from a nice and secure password at this point. It's all
| about entropy and byte mapping.
| [deleted]
| needle0 wrote:
| Gonna be eagerly waiting for the time when we _can_ finally
| change our behavior at will, be it neural implants or
| nanomachines or whatever other method of direct intervention to
| the brain.
| wahnfrieden wrote:
| we have less invasive solutions available already
| lll-o-lll wrote:
| > Take my father, there is no way he could use a password
| manager, or two factor, it's just never going to happen.
|
| Have you tried the "passkey" integration on Apple devices? If
| so, do you think your father would be able to use that?
|
| To me, it seems such a simple UX that I can't imagine even the
| most technically illiterate being unable to use it. In the
| Apple ecosystem, there is literally no configuration for the
| "password manager" it's just integrated into the Apple Account.
| You'd go from a notebook of passwords to just one (the main
| Apple ID password, for recovery etc).
|
| Obviously "passkey" is not available in most sites yet, but I
| imagine that once it is, the switch might be pretty painless
| for the non-tech savvy. Assuming the other device manufacturers
| can provide similar seamless integration.
| wilg wrote:
| Yeah, exactly. The writing is on the wall for password based
| authentication. I think this is all going to look very
| different in a year or two.
| anderspitman wrote:
| Is the cost of getting phished really lower than the cost of
| learning a password manager for your dad?
| samwillis wrote:
| Is the cost of lung cancer lower than smoking?
|
| Some people will just never change a behaviour.
| anderspitman wrote:
| I find there are generally two reasons people use
| analogies. The first is to make a concept easier to
| understand. The second is to subtly change what is being
| argued in order to make their position seem stronger. I did
| the second for years without realizing what I was doing,
| and still fall into the trap.
| Eisenstein wrote:
| I find there are generally two reasons people pick apart
| argument structure rather than deal with an argument's
| content. The first is to point out fallacies or
| rhetorical devices which are invalid or illogical. The
| second is because they realize their position is too weak
| to confront it directly.
| anderspitman wrote:
| Are you sure you understand what my position is? Care to
| strongman it?
|
| Fwiw I think you're actually right that HN tends to spend
| way too much time on semantics, and I'm certainly guilty
| of that myself sometimes
| Eisenstein wrote:
| I am not arguing for or against your position. I am using
| the form you just used in order to mirror how annoying
| doing something like that is.
| anderspitman wrote:
| Your initial intent was clear. I was simply trying to
| move this towards something productive. Clearly I failed
| Eisenstein wrote:
| You don't seem to be 'simply' doing anything. Everything
| you have posted besides the first comment about phishing
| is some kind of dodge which uses obvious manipulation
| tactics, for instance saying 'I do that myself
| sometimes', which is a cop method for encouraging
| confessions, or 'you can have the last word' works to
| actually let _you_ have the last word. Stop doing that.
| samwillis wrote:
| Or the third to to illustrate the argument in another
| context.
|
| I usually avoid analogies of HN as you are often called
| out on the technicalities of them. And you are right that
| can often damage an argument.
|
| However, I have argued that changing peoples behaviour,
| even when their current behaviour is bad for them, is
| often impossible despite all evidence, from the
| beginning.
| anderspitman wrote:
| > Or the third to to illustrate the argument in another
| context.
|
| This is still case 1.
|
| I actually agree with you that some people with bad
| security habits will never change their behavior, but do
| you really feel that someone using passwords in a
| notebook because that's what they're comfortable with is
| in the same class of behavior as someone addicted to
| nicotine?
|
| Feel free to have the last word here. 1 on 1 HN threads
| more than 3 deep rarely result in productive
| conversation. Cheers
| xcxcx wrote:
| Well they are going to have to change, because these people
| will be retired and for the most part depending on a
| government's check.
|
| There's a cost to society to carrying over such a technological
| deadweight loss and these people are free riders.
| pierat wrote:
| > There's a cost to society to carrying over such a
| technological deadweight loss and these people are free
| riders.
|
| The same capitalistic analysis can be said for fetuses,
| infants, and children up to working age.
|
| Is your proposal for infanticide the same as your
| gerontocide?
| marcus0x62 wrote:
| Yes, the abject failure of the tech industry to create usable
| and secure software is the fault of...checks
| notes...retirees.
| samwillis wrote:
| Gosh, you're fun.
| tylerrobinson wrote:
| Using economics terminology doesn't make this insensitive
| opinion any more valid.
|
| Technology is for people, not the other way around.
| _Algernon_ wrote:
| The existence of the attention economy demonstrates that
| your statement is blatantly false.
|
| Technology is not for people. It ought to be, but it is
| not.
|
| Technology exists so that the aristocracy can line their
| pockets and control the populace more efficiently.
| drdaeman wrote:
| Good sir, if we're going for fantasy/conspirological
| themes, we have to go deeper than this distasteful
| banality.
|
| People _and_ technology _and_ aristocracy are for the
| memes. It 's just one huge anthill where the ideas
| evolve, living on biological (and then technological)
| foundations.
|
| Power hubs (be it aristocracy or any other form of
| government) is just a convenient mechanism for spreading
| ideas - politicians and millionaries are just
| superspreaders (in their respective ages, but they're
| losing it to the technological platforms - and of course
| there's a struggle). So is technology. So are people.
| It's all an evolutionary process - just notice how
| designed systems rarely win, nearly always giving to
| chaotic blind evolution - whatever catches more
| brainspace truly matters, not what works best. If the
| memetic winds will blow in a certain direction, LLMs may
| make us obsolete, but not in the way we think they would.
|
| This comment is sponsored by "You think the moon is
| real?" meme. Sorry (not sorry).
| xcxcx wrote:
| Nobody gets to decide what's more or less sensitive.
| Younger generations can argue being rendered homeless due
| to mass housing affordability issues is also insensitive.
| hkt wrote:
| It is incredibly useful to powerful people to keep at
| this generational war narrative, as it keeps people who
| might otherwise work together from doing so with an aim
| of crushing the power of the wealthy.
|
| The fact is, anti-human attitudes to both housing and
| technology are harmful everywhere. Nobody has to "win" at
| the other side's expense here.
| xcxcx wrote:
| Some games are zero sum and some aren't. Everyone is more
| secure if a large bank replaces 2FA over unencrypted SMS,
| even though some may be inconvenienced.
|
| Leveling down on everyone's security in exchange for
| usability for a segment of the population is not a
| realistic long-term strategy.
| hkt wrote:
| As opposed to encrypted SMS? I'm genuinely intrigued at
| the idea that's a thing.
|
| As for the rest, is there any actual evidence of
| widespread interception of SMS 2fa actually being a
| problem?
| lcnPylGDnU4H9OF wrote:
| Calling such people "technological deadweight" and "free
| riders" is the insensitive thing, regardless of the
| veracity.
| _jal wrote:
| > Nobody gets to decide what's more or less sensitive
|
| That's simply incorrect. Everyone gets to decide.
| detourdog wrote:
| I let people set their own password. This is like canary
| letter for them to know if anyone accessed their data. If
| sysadmins need access they take it and go through a new
| password rotine with the user.
|
| I also have no password requirements (other than non-blank)
|
| I do this because I see it as user centric. I have never
| had a problem.
|
| One environment requires no privacy expectation. That
| environment we use simple nouns all in the same category.
|
| All the environments are full SSO they only need to login.
| FredPret wrote:
| Yeah, shape up and learn to code, grandma!
|
| In all seriousness, tech must adapt to humans. Engineers are
| at their best when they aren't dictators
| [deleted]
| cm2012 wrote:
| It's not just old people. I'd say 80% of people would not use a
| website with that system.
| gcanyon wrote:
| > Take my father, there is no way he could use a password
| manager...He has a notebook of passwords
|
| Your father _does_ use a password manager: a slow, very
| inconvenient one. If you could teach him to reach for ctrl-c
| /ctrl-v instead of a pencil, it would be easier for him.
| tomsmeding wrote:
| It would be easier for you, who (I suspect) has, like most of
| us here on HN, a good understanding of what happens on a
| computer, how to control that, how to manage their software,
| how to be aware of what is on the foreground when and taking
| input when. How to recognise various applications and seeing
| the difference between materially different ones that try to
| look the same.
|
| Your notebook will look markedly different from a website
| that tries to imitate your notebook. Your password manager
| will only look markedly different from a website imitating
| your password manager if you have a certain level of
| awareness and acuity of what happens on-screen and what it
| means. I think GP's father doesn't have that awareness, and
| never will, by choice. They choose to spend their energy
| elsewhere.
|
| Younger generations had no choice and will have spent that
| energy already by the time they're 12 years old, and have
| these problems less.
| SoftTalker wrote:
| I think you sell older people short on what they are and
| aren't aware of. I think it's more that they see computer
| technology as a necessary annoyance of the modern world and
| not anything helpful. They used to manage their bank
| balance on a ledger in the back of their checkbook, and
| _that seems easier to them_ than having to sit down in
| front of the computer or use an app on a small screen that
| 's constantly throwing popups in their face, either ads or
| little "helpful tips" about this month's new features.
|
| I'm getting close to 60, but I've been programming and
| working with computers since in was in 6th grade. When I
| was in my 30s, paying my bills meant sitting down at the
| table once a month with my checkbook, stack of bills, and
| book of stamps. Open a bill, write a check, put a stamp on
| the envelope, repeat. It took maybe 15 minutes and was very
| easy. Compare that to opening a different website, with a
| different username and password and maybe TOTP code or SMS
| code, for each bill I need to pay. It's slower and more
| complicated.
|
| There is no online payment method I've seen that seems
| easier to me than just writing a check. Of course I rarely
| write checks these days, so I use the apps and websites and
| feel annoyed every time I do.
| troupo wrote:
| > I think it's more that they see computer technology as
| a necessary annoyance of the modern world and not
| anything helpful.
|
| They are correct aren't they? None of the modern software
| is made to serve and help the user. It's made to serve
| advertisers and be promotion vehicles for product
| managers.
|
| I am a computer guy. I am constantly and continuously
| irritated by all the crap in software. I see how my non-
| techie mom struggles, and it's several orders of
| magnitude worse for her.
|
| So I totally agree with you.
| tomsmeding wrote:
| I am not at all claiming that all people above a certain
| age have difficulty with these things! Though it is
| usually people above, say, 40 who feel this way -- and
| this is not a negative thing: it may well be just because
| they remember that a different way existed. I.e. most
| people with tech difficulties are older, but many older
| people have no tech difficulties.
|
| Though you are also correct that dealing with
| "technology" today requires a certain level of pain
| tolerance. Good UX exists but is rare, and authentication
| is still a mess basically everywhere if you don't want to
| do OAuth and centralise it to the behemoths. "Poweruser
| apps" can be extremely empowering, but always have a
| steep learning curve, sometimes very steep; they can help
| making your dayjob much easier, but typically help nought
| with, say, filing your taxes or paying your bills.
|
| Disclaimer: am 25 years old.
| troupo wrote:
| > Though it is usually people above, say, 40 who feel
| this way
|
| and immediately you write this:
|
| > Though you are also correct that dealing with
| "technology" today requires a certain level of pain
| tolerance. Good UX exists but is rare
|
| So it's not just 40+ year olds who feel this way
| tomsmeding wrote:
| The first was about having _difficulty_ , the second
| about not liking it. Again, the (fuzzy, approximate)
| implication goes only one way: having difficulty breeds
| dislike, but dislike does not imply difficulty.
|
| EDIT: you are correct I didn't word my original message
| correctly. Perhaps you have a point.
| kelnos wrote:
| > _There is no online payment method I 've seen that
| seems easier to me than just writing a check._
|
| Autopay. I only pay one bill manually, twice a year,
| because they don't allow autopay (property taxes).
| Otherwise I just don't think about it.
|
| Sure, you may not like autopay for whatever reason, but
| that's a choice. The option is there.
| SoftTalker wrote:
| Yeah and I do use autopay for some very predictable
| things like utilities. I'm not totally comfortable with
| giving someone access to draw from my checking account
| whatever amount they claim I owe, but realistically these
| days a paper check becomes an ACH payment so I figure
| there are non-zero chances for error that just cannot be
| easily avoided.
| jefftk wrote:
| _> I 'm not totally comfortable with giving someone
| access to draw from my checking account whatever amount
| they claim I owe_
|
| It's not comfortable, but every time you write a check
| you're doing exactly this.
| janalsncm wrote:
| Well a check is authorization to withdraw a specific
| amount (which you can verify is reasonable) after a
| specific time (which you can verify the funds will be
| good).
| jefftk wrote:
| But the information on a check is sufficient for anyone
| to initiate an electronic funds transfer from your
| account.
| no_wizard wrote:
| I highly recommend setting up autopay via your banks bill
| pay system. Less organizations having your account info
| is a good thing, and it's super convenient for bill
| tracking.
| samwillis wrote:
| > I think GP's father doesn't have that awareness, and
| never will, by choice.
|
| This! I mention password managers, two factor or just try
| and get him to improve his passwords and his eyes glaze
| over and can see him beginning to nod off. Probably
| somewhat my fault for always bring them up after a meal
| when he's probably already half way to napping...
| hgsgm wrote:
| My password manager is built into my browser. I just push the
| button to login.
| scrollaway wrote:
| Indeed. I have converted my mother to 1Password and it's
| working great for her once she got past the initial learning
| curve.
| comboy wrote:
| > He has a notebook of passwords, that's how he works and he
| won't change.
|
| So do I for some passwords, physical security is way easier.
| ClumsyPilot wrote:
| > He has a notebook of passwords, that's how he works and he
| won't change.
|
| A notebook in a locked safe is the most secure datastore for 90
| - 98% of the population - depending of how deeply you distrust
| NSA.
| highwaylights wrote:
| This is only true if you're very selective about which
| threats you want to acknowledge.
|
| If someone breaks into my house I'd rather they just got my
| TV and some belongings rather than my life savings.
| NegativeK wrote:
| Most people are more at risk from bad passwords and website
| breaches than from home burglary.
| Y-bar wrote:
| I'd wager that >99% of all burglaries are looking for
| physical possessions which can be sold for a quick buck.
| Not looking for random notebooks of passwords. So locking
| it in a safe might not be optimal because it will be like
| putting a spotlight on it.
| samwillis wrote:
| Something like 90% of burglaries are looking for car
| keys. That's why I keep my keys by the front door in
| eyesight on anyone who comes in. I have insurance, and
| don't want a thug wandering around my house.
| DenisM wrote:
| Now there's a thought. Clever.
|
| Does it make sense to also keep some decoy items, like an
| old MacBook in plain sight?
| ClumsyPilot wrote:
| > If someone breaks into my house I'd rather they just got
| my TV and some belongings rather than my life savings
|
| I think this is very unlikely. For one, the notebook does
| not contain all the information - say "Bank1 Password" -
| which bank is that? What's the username? What about 2FA?
|
| Secondly, surely the whole point if a safe is that it's
| bolted down and hard to burgle / steal?
| Groxx wrote:
| fwiw I haven't ever been in a house with a bolted-down
| safe, nor am I aware of anyone I know ever having one.
|
| they _exist_ but uh. most people just have portable fire-
| safe boxes as far as I 've seen. or nothing.
| kneebonian wrote:
| This reminds me of a quote from James Mickens regarding
| computer security.
|
| "Unfortunately, large swaths of the security community are
| fixated on avant garde horrors such as the fact that,
| during solar eclipses, pacemakers can be remotely
| controlled with a garage door opener and a Pringles can.
| It's definitely unfor- tunate that Pringles cans are the
| gateway to an obscure set of Sith-like powers that can be
| used against the 0.002% of the population that has both a
| pacemaker and bitter enemies in the electronics hobbyist
| community. However, if someone is motivated enough to kill
| you by focusing electromagnetic energy through a Pringles
| can, you probably did something to deserve that. I am not
| saying that I want you dead, but I am saying that you may
| have to die so that researchers who study per-photon HMACs
| for pacemaker transmitters can instead work on making it
| easier for people to generate good passwords."
|
| My point being if someone's motivated enough to break into
| your house to steal your passwords in order to steal your
| life savings, that's probably an outside scenario, given
| most B&Es are junkies looking to score enough for their
| next high.
| crote wrote:
| > This step is commonly something like "enter the code in an
| email we just sent" when trying to login.
|
| Because email is insecure, and there is zero guarantee that your
| login email will arrive before the token expires. Your token
| _does_ expire, right?
|
| > We are literally living through the gradual phase-out of third-
| party cookie.
|
| Yes, and a "remember this device" uses a first-party cookie, so
| it isn't affected.
|
| > My own browser erases all cookies from an origin immediately
| after the last tab from that origin is closed
|
| So you are intentionally breaking the web and complaining that
| things are cumbersome? Gee, I wonder why.
|
| > [..] yet that same website is happy to let me authenticate
| using an API key for API access as a single authentication step.
| No "2FA" here.
|
| Yes, because that API key is often used to _sign_ the request,
| contains enough entropy to make guessing impossible, and because
| the URL is hardcoded in the app phishing is impossible.
|
| > guaranteed use of a high-entropy secret obviates the need for
| additional authentication
|
| No, it does not. See: phishing.
|
| Forcing the use of website-generated passwords is cute, but doing
| basic entropy checks on a user-provided password pretty much
| solves the issue anyways. Why bother alienating a significant
| fraction of your user base?
|
| Authentication is pretty much a solved problem. Use a password
| locker encrypted using a single remembered key for the "something
| you know" part, and use a physical Webauthn token for the
| "something you have" part. Stop trying to reinvent the wheel,
| it'll only end up annoying your users.
| ec109685 wrote:
| The idea that email isn't secure but is a key link in the
| registration and password reset flow always strikes me as odd.
|
| Passkeys can't come soon enough, and email providers better
| make sure they are never compromised.
| justsomeadvice0 wrote:
| > doing basic entropy checks on a user-provided password pretty
| much solves the issue anyways.
|
| No it does not. Users will find one high-enough-entropy variant
| of their password, and reuse it across all sites for life.
|
| > Authentication is pretty much a solved problem
|
| Hrm. It might be solved for you and users like you - but it
| depends on your site's demographics: most internet users on the
| whole will not know anything about encrypted "password lockers"
| and "physical Webauthn tokens". Browser-managed passkeys, on
| the other hand, stand some chance of being easy enough to use
| while enforcing good security and high entropy secrets, but
| lack widespread adoption so far.
| ghusto wrote:
| > Because email is insecure, and there is zero guarantee that
| your login email will arrive before the token expires. Your
| token does expire, right?
|
| That's a bit like saying laptops aren't secure. Well okay,
| laptops are not inherently secure, but my instance of laptop is
| secure (enough). Same with e-mail; there's nothing inherent in
| e-mail that would make it secure, but the way my e-mails have
| been set is secure (again, "enough" for practical reasons).
|
| >> My own browser erases all cookies from an origin immediately
| after the last tab from that origin is closed >So you are
| intentionally breaking the web and complaining that things are
| cumbersome? Gee, I wonder why.
|
| Clearing cookies isn't breaking the web. Some of your websites
| functionality may require things to happen again if I clear
| cookies, but a) that seems like a you problem, and b) doesn't
| seem broken to me.
|
| > Yes, because that API key is often used to sign the request,
| contains enough entropy to make guessing impossible, and
| because the URL is hardcoded in the app phishing is impossible.
|
| Not sure where you're seeing this "often", but most services I
| have API keys for work _exactly_ like passwords. I have to jump
| through a few hoops to get a working key, true, but once I have
| it, it's essentially a password, and used in the same way.
|
| > Authentication is pretty much a solved problem. Use a
| password locker encrypted using a single remembered key for the
| "something you know" part, and use a physical Webauthn token
| for the "something you have" part. Stop trying to reinvent the
| wheel, it'll only end up annoying your users.
|
| I don't feel like it's a solved problem if normal people refuse
| to do that. That's a solution in the same way that the advice
| "Everybody be nice to each other" is going to make the world a
| better place.
| [deleted]
| [deleted]
| [deleted]
| Attummm wrote:
| How would you share the password with the users without revealing
| it to others?
|
| How would a users use different devices?
| Pxtl wrote:
| Honestly, unless you're a major cloud/OS provider like
| Google/FB/MS/Apple, you shouldn't be managing passwords at all.
| Let the pros do that. You just use an authentication standard via
| a 3rd party.
|
| If you aren't big enough to maintain your own operating system
| and web browser, you shouldn't be storing passwords.
| lolinder wrote:
| I do not want to log in with Google or GitHub or Apple or
| anything else. I _want_ an account on your site, even if you
| 're bad at security (though you should at least store hashes
| and not plaintext passwords). Keeping track of another login is
| as simple as adding a new password to my password manager, and
| that gives me _much_ more control over my digital life than
| logging into everything with my Google account.
| Pxtl wrote:
| Okay but don't come crying to me when a bunch of your users
| get hacked because they used the same password on your site
| as they use on somecrappyforum.io which leaked their password
| db.
| anderspitman wrote:
| I agree social SSO is the gold standard in terms of UX, but
| it's also a privacy disaster. What we really need is for
| someone to make a Let's Encrypt for login. A nonprofit that
| provides SSO in a privacy respecting manner.
| Pxtl wrote:
| I agree. I'd much rather "login with Firefox Login" or
| "Ubuntu One" than Google or Facebook for SSO. But failing
| that, expecting end users to manage passwords to every site
| (and every site to store passwords) is still irresponsible.
| no_wizard wrote:
| I prefer so called "passwordless" systems that use a combo of
| magic links and 2 factor authentication. I do think passwords are
| an outdated modality for non local accounts, most of the time.
|
| If anything they should only be used for resetting the account
| coupled with successful use of a 2nd factor, I suppose, but
| recovery keys aren't a bad compromise depending on the user
| kelseyfrog wrote:
| Ikea effect. People are more likely to complete the new user
| funnel if they felt they had a role in building it.
| anderspitman wrote:
| This made me chuckle, and it honestly might be true.
| goalieca wrote:
| With passkeys they won't. Let's move on already!
| laputan_machine wrote:
| There is an overwhelming amount of superfluous text in this
| article.
|
| The author's solution:
|
| > Rather than allowing a user to set their own password,
| passwords can be issued in exactly the same way as API keys are
| now: a high-entropy password is randomly generated by the issuing
| website, and the user is shown the password once only and asked
| to record it. If the password is lost, a new password must be
| generated using the same process. The user cannot choose their
| password, but can get a new randomly generated one in the event
| of compromise. The password essentially becomes indistinguishable
| from an API key.
| nvahalik wrote:
| He also claims that TOTP storage in the password manager is
| useless. It's only useless if the entire password manager is
| compromised. If your attack vector is a keystroke logger, or
| compromise of a single password via a dump, or even someone
| having written down the password... storing the TOTP is still
| effective.
| sjadoinqwoeihad wrote:
| Keylogger would still get the TOTP code. Dump would include
| the TOTP secret. Why write only the password down if you
| still need password manager for the TOTP code?
|
| I think I mostly agree TOTP in password manager is useless,
| but it's not worse than not having TOTP at all so it's
| whatever.
| [deleted]
| ghusto wrote:
| 2FA protects two different attacks: 1) Hacker obtaining
| your password (through phishing, compromise of third party,
| etc.) 2) _You_ actually being compromised yourself somehow.
|
| It is still effective for the first protection if you store
| your codes in your password manager, but less for the
| second. I say less, and not completely, because if your
| machine is compromised, gaining access to your phone too is
| only a matter of time. Of course this can be mitigated why
| proper hardware tokens, but most people aren't using those.
| r00fus wrote:
| Keylogging + dump of password manager requires 2 different
| but related compromises, no?
|
| Ultimately if someone can log keystrokes and has access to
| your device, it's game over.
| orev wrote:
| A TOTP code must be marked as "used" immediately after
| processing it, so an attacker using a keylogger would have
| only a few seconds at most to use the code, assuming the
| user typed the code from the password manager instead of
| copy/paste.
|
| The protection offered for TOTP in a password manager is
| from people who reuse the same password on multiple sites
| and some other site gets hacked. In that case, the attacker
| would not be able to login, regardless of having the
| password.
|
| Also, once a system is so thoroughly compromised that the
| attacker can install a key logger or dump a password
| database, that system and all the user accounts are already
| completely compromised.
|
| TOTP at this point is essentially a forced password that
| changes every 30 seconds instead of an actual additional
| factor, however in many cases that's good enough.
| jiveturkey wrote:
| you missed the attack. a keylogger doesn't capture the
| TOTP (and fully synchronous 0-reuse TOTP isn't possible
| on global scale, instead you catch it in audit) a
| keylogger captures the master password to the pwm that
| stores the TOTP secret.
| r00fus wrote:
| But then they have to have physical access to your pwm or
| an export of it. If it's cloud-based, I'd have to assume
| there's some additional auth done for non-approved
| devices, or it's a bad cloud pwm.
| kemayo wrote:
| In the keylogger case, it still makes the attack more
| complicated -- they need to steal your login before that
| code expires, so rather than passive password-harvesting it
| has to be an _immediate_ attack.
| skrebbel wrote:
| This is basically what passkeys are, right? Except the
| autogenerated password isn't even shown to the user, just
| stored immediately in the user's password manager.
|
| (I recognize that it's a bit more involved, eg if i get it
| right, passkeys add some public key encryption to the mix to
| avoid sending the "password" over the wire needlessly often
| etc, but those are just icing on the cake as far as I'm
| concerned)
| arnarbi wrote:
| There isn't encryption nor a generated password involved with
| passkeys. Rather, your device generates a private key and
| stores it in your password manager - and only the public key
| is sent to the server.
|
| When you log in later, the server uses an API to give your
| client a random unique challenge (just some bytes), you
| unlock and approve and the pwm signs some stuff including the
| challenge and sends the signature back. The server verifies
| with the public key, and is satisfied because only your
| private key could've generated that signature.
|
| But you are exactly right - this is detail and the UX is
| essentially the same as having the pwm generate random
| passwords that you never get to see or copy.
| skrebbel wrote:
| There isn't encryption involved? I mean how can you use
| public and private keys without encryption?
|
| Anyways yes, I agree otherwise. That said for all intents
| and purposes, the private key is a password. It's the thing
| you store that gives you access to the service. That it's
| not transmitted, but instead the whole public key /
| challenge response dance is done, is IMO sufficiently well
| summarized as "well, it's a _special kind_ of autogenerated
| password, which can't be insecurely transmitted or badly
| stored by the service".
|
| If we really want people to adopt passkeys we gotta begin
| talking about them in terms people understand. I consider
| myself pretty tech savvy and it took me like 6 articles
| until I finally grokked that a passkey is just an
| autogenerated password (plus some free automatic bonus
| security that doesn't affect my UX)
| ec109685 wrote:
| Important to emphasize that passkeys are phishing
| resistant. Unlike passwords that allow you to copy and
| paste them to a website (hmm, auto complete isn't working
| on this broken website, I can just go find it and paste it
| in -- boom phished).
| croes wrote:
| A password can be stored offline without any electronic
| device or even be memorized only.
|
| Passkey depends on your device.
| justsomeadvice0 wrote:
| While you can't memorize it (memorizing a fair amount of
| entropy would take an intelligent human quite some time),
| you can of course store them offline (it's just a key).
| Today's initial implementation on macOS restricts
| exporting, but that is supposed to be added according to
| reliable Apple devs:
| https://hachyderm.io/@rmondello/110329118270492669
| croes wrote:
| >you can of course store them offline
|
| >Today's initial implementation on macOS restricts
| exporting,
|
| So you can't. Will be able. How long can Tesla owner earn
| money with their self driving Tesla?
|
| If you can export and import them, isn't that a security
| risk?
| brasic wrote:
| It sounds almost exactly like the mechanics of a session cookie
| as implemented on nearly every website on earth. Exchange a
| password for a bearer credential that is randomly chosen and
| revocable. There are only so many basic ideas in security.
| Someone wrote:
| > Rather than allowing a user to set their own password,
| passwords can be issued in exactly the same way as API keys are
| now: a high-entropy password is randomly generated by the
| issuing website, and the user is shown the password once only
| and asked to record it. If the password is lost, a new password
| must be generated using the same process.
|
| I don't understand that logic. Normally, systems generate API
| keys and show them to a person _knowing_who_that_person_is_.
|
| I, when I lose my password, the system can generate a new one
| for me even when I'm not logged in, how can it know it's doing
| that for me and not for someone claiming to be me?
| IshKebab wrote:
| I don't understand your confusion. The generated high entropy
| password would be shown to you with the system knowing who
| you are too - because you just registered or reset your
| password.
| Drew_ wrote:
| > how can it know it's doing that for me and not for someone
| claiming to be me?
|
| By emailing you a OTP :)
| hartator wrote:
| > There's not really a good reason for a user to be able to set
| their own password unless they want to set their password to
| something lower in entropy to make it memorable, or reuse it
| between sites, both of which are deviations from the "best
| practice" password safe usage model.
|
| Yeah, but at the same time if you keep loosing access to your
| accounts because you can't remember your password, you are just
| 1FA with your email or phone number. Might as well then skip
| passwords entirely and use sign in via phone or email.
| krupan wrote:
| That's pretty much the point the blog post is making.
| raesene9 wrote:
| The advice on passwords very much depends on the level of control
| that a system operator has on its userbase, and the threat model
| of the site.
|
| In an end-user B2C style website, whilst passwords (and MFA) etc
| are needed for Authentication, the operator has limited control
| over users and if you annoy your users too much, with things like
| mandatory system generated "high entropy" passwords, they'll stop
| using your site (assuming there are other options available).
|
| In a corporate style service it's different as the operator can
| mandate things like the use of MFA and the use of password
| managers.
|
| I've seen systems that did the "system controlled password" thing
| in the past and, if done incorrectly, it just leads to users
| writing their passwords down somewhere (e.g. sticking them to a
| post-it note under their keyboards).
| jdthedisciple wrote:
| I've said it before and I'll say it again (and yes let it rain
| downvotes):
|
| I don't understand this whole discussion and maligning of
| passwords.
|
| You cannot save all people. Some fixed %-age of people will
| always become victims - either by choosing a terrible password or
| by being shot in the foot by some terribly complex 5FA device-
| based passphrase scheme that attempts to protect them but ends up
| betraying the user once they replace their phone or it breaks or
| for any other mundane reason.
|
| User picked passwords (1FA) are and will always be the single
| best solution that has ever existed for authentication,
| considering everything from security to usability and
| practicality, wholistically.
|
| If I sign up for some crappy service that I'll barely even
| remember a week later I should be good to go setting my password
| to "asdf" and that's everything I need to log in.
|
| Fuck everything else.
| https://news.ycombinator.com/item?id=36717356
| mike_hock wrote:
| Based.
|
| It's trivially easy to generate passwords with 128 bits of
| entropy and have them managed by a password manager.
|
| Until the password manager gets hacked. Well, tough shit. If
| your primary device gets hacked, the hacker just has to wait
| until the next time you log in with the bullshit gazillion
| factor authentication.
|
| And it always collapses to 1FA for the lost password recovery
| process, which you're gonna have to provide if you want
| customers.
| r00fus wrote:
| > Until the password manager gets hacked. Well, tough shit.
| If your primary device gets hacked, the hacker just has to
| wait until the next time you log in with the bullshit
| gazillion factor authentication.
|
| Can you elaborate? This scenario assumes that a) the primary
| device is the only 2FA option b) there is no one-time codes
| and c) the attacker persistently waits until a 2FA request
| comes through then somehow hijacks it with their own
| connection request?
| mike_hock wrote:
| Nah, he just hijacks your session directly.
| krupan wrote:
| I kind of see where you are coming from, because it's true that
| every alternative to passwords that seems to be gaining
| traction right now is horribly complicated. Webauthn and
| passkeys are like the IPv6 of security upgrades. Waaaaay, way
| more than is needed to improve upon the security of passwords.
|
| Now, the rest of your argument kinda sucks, sorry to say. There
| are things we can do to make everyone's personal information
| more secure. Using childhood clubhouse password "technology" is
| not cutting it. We can definitely do better than shared secrets
| that get leaked to the whole internet on the regular. We can be
| more secure with an easier to use UI. Yes, people will still
| get pwned, but less people will, the bad guys will have to work
| harder.
| H8crilA wrote:
| I don't understand your point.
|
| Do you know that major tech companies saw a near 100% reduction
| of successful phishing attacks after adding yubikeys? The
| population there is hardly uneducated, yet they still had quite
| a few break-ins. Some of the companies have also nearly removed
| passwords, changing the minimum length requirement to something
| like 5 lowercase characters. They still experience a near zero,
| or zero, phishing success rates.
| ghusto wrote:
| > Do you know that major tech companies saw a near 100%
| reduction of successful phishing attacks after adding
| yubikeys?
|
| His point (my emphasis):
|
| > User picked passwords (1FA) are and will always be the
| single best solution that has ever existed for
| authentication, _considering everything from security to
| usability and practicality, wholistically_
|
| So his point is that if you consider all aspects
| wholistically, including usability and practicality,
| passwords are the best solution.
|
| I'm not saying I agree, but a 100% reduction of successful
| phishing attacks after introducing Yubikeys only considers
| security, and not the other factors.
| akira2501 wrote:
| > Do you know that major tech companies saw a near 100%
| reduction of successful phishing attacks after adding
| yubikeys?
|
| The actual question is: "Did they see an INCREASE in other
| types of attacks after using yubikeys?"
|
| To presume that these actors who were willing to go to some
| illegal lengths to get this information in the first place
| just "gave up" because "yubikeys exist" is a dangerous way to
| process these facts.
| jdthedisciple wrote:
| Sure, you could even reduce phishing attack success rates to
| nearly 0% by having users authenticate with a sample of their
| DNA.
|
| Does that mean it's a great idea?
|
| What about losing the yubikey?
|
| In any case it's a different matter when it comes to high
| stake scenarios, in which case I don't mind something
| slightly more sophisticated.
|
| But not as the default for everything.
| superkuh wrote:
| >having users authenticate with a sample of their DNA.
|
| I know it's not your point and I agree with everything
| you're saying in this thread 100%, but DNA based login
| would be a username, not a password. Like all biometrics.
| And it'd have a really bad false positive rate if you're
| just doing restriction enzyme cut location tests like lots
| of "police work". A full exome scan ~$300-500/per might do
| it.
| antonjs wrote:
| And as you point out, the problem with biometrics is that
| once they're stolen or copied, there's no changing them.
| Particularly your DNA.
| seabass-labrax wrote:
| You cannot save all people - too true. But remember that you,
| actually all of us, are indirectly the victim of other peoples'
| mistakes:
|
| - we lose contact with people because they get locked out of
| their email
|
| - we pay more in bank account fees to subsidise fraud
| compensation
|
| - we have our personal information stolen because others chose
| weak passwords
|
| Given how much we suffer from other peoples' poor choices,
| there is a huge incentive to somehow stop people from making
| poor choices. By analogy, we all benefit from fences by cliffs
| because the family of the unlucky soul who wandered off it, the
| emergency services and their funders all suffer too. If it
| weren't for values like personal freedom, aesthetics, financial
| cost and an apathy towards accidents, there would be no
| clifftop in the world without a fence by it.
| romwell wrote:
| >- we lose contact with people because they get locked out of
| their email
|
| I've been locked out of my email because Google insists that
| "we don't recognize your device", and locked out of my other
| accounts _because my phone was stolen_ , not because I didn't
| remember my password.
|
| People forgetting passwords isn't a problem that's solved
| with other schemes. It's a problem that's exacerbated by
| them.
|
| >- we pay more in bank account fees to subsidise fraud
| compensation
|
| Bank account fees, seriously? I can't remember the last time
| I've paid any.
|
| In any case, worrying about saving the _banks_ a few bucks is
| dead last on my list of worries.
|
| >- we have our personal information stolen because others
| chose weak passwords
|
| If _our_ info can be stolen because _someone else_ chose a
| weak password, the weak password isn 't the problem. It's the
| system that was badly designed in the first place.
|
| >Given how much we suffer from other peoples' poor choices,..
|
| We don't.
|
| >By analogy, we all benefit from fences by cliffs
|
| The analogy doesn't hold because you have to first show that
| alternatives to passwords are _better for the users_ , even
| those in the category you mention.
| seabass-labrax wrote:
| > People forgetting passwords isn't a problem that's solved
| with other schemes.
|
| Sorry, I should have clarified: that was in reference to
| users being unable to successfully use the parent's
| hypothetical 'terribly complex 5FA device-based passphrase
| scheme'. Passwords don't get any blame here.
|
| > Bank account fees, seriously? I can't remember the last
| time I've paid any.
|
| OK, fractionally lower interest growth then, or less
| frequent premium bond wins. In any case, the bank is going
| to find a way of passing the cost of business to you, so
| you have an indirect incentive for their business to be
| cheaper to them.
|
| > If our info can be stolen because someone else chose a
| weak password, the weak password isn't the problem. It's
| the system that was badly designed in the first place.
|
| That is correct for some kinds of personal information,
| like how storing documents on a 'cloud' without client-side
| encryption is a badly designed system for privacy. However,
| there are genuinely some occasions where a third-party
| needs to have access to (not just verification of) your
| information, but also has a responsibility to keep their
| copy secure. A hospital might need to see your medical
| records to do its job, for instance.
|
| > The analogy doesn't hold because you have to first show
| that alternatives to passwords are better for the users,
| even those in the category you mention.
|
| I completely agree with you. All I'm saying is that a lot
| of people will try to replace passwords (because we all
| have an incentive to improve the situation), even if their
| replacement fails at being better for users!
| jsunderland323 wrote:
| Re: bank account fees. I think OC was just making the point
| that one institutions' lack of security practices gets
| passed to the entire system as a way to offset fraud costs,
| we all universally eat this stupid cost.
|
| An example of this is chargeback fraud on marketplaces. The
| way the fraud works is someone buys a bunch of credit card
| numbers off of the dark web due to some websites' bad
| security practices and a data breach. The fraudster then
| ATOs a merchant account on some marketplace platform or
| makes a fake account, e.g. Doordash, Airbnb, Shopify, etc.
| The ATO is usually possible because some subset of the
| merchants of the platform use the same passwords on another
| website that has been compromised, again, some data set is
| sold on the deep web. The fraudster then either has to
| change the payout method of the marketplace merchant
| account, which they can usually do by ATOing an acquiring
| bank that they can access the funds in some way, again due
| to another external institution with tenuous security
| practices.
|
| Finally the fraudster charges all the stolen credit cards
| and in most cases leaves the platform taking the liability.
| This results in the platform pushing up take rates against
| their merchant accounts, which almost always gets passed
| back to the consumers of the service (us) by increasing the
| prices of the service.
|
| The problem with passwords is that we expose ourselves to
| everyone else's negligence. You might handle passwords with
| all the best security practices to be known but you expose
| yourself and your users to every other system's
| incompetence. It wasn't until I saw this play out, that I
| understood passwords aren't just a disservice to the
| negligent compromised user but really to the whole
| ecosystem of the internet that partakes in password
| authentication.
|
| Yes, there is always a trade off in security and friction.
| This has always been true. But if we know passwords are
| faulty and essentially useless, why continue with such a
| bad practice? To reduce friction to a maximal extent? By
| that logic we might as well throw out the concept of
| security altogether. Why not just make it so a user only
| has to enter their email/username and nothing else? Let me
| know how that goes for you. I think webauthn is likely the
| sustainable, long term solution but we've got a ways to go
| before some of the inane thinking around password
| preservation dies out.
| akira2501 wrote:
| > - we lose contact with people because they get locked out
| of their email
|
| This is a temporary condition, and they can create another
| email or communicate via other means. If some part of your
| life is highly dependent on a single email address remaining
| 100% available, you've made a mistake already.
|
| > - we pay more in bank account fees to subsidise fraud
| compensation
|
| I have a feeling that if you got rid of passwords, new forms
| of fraud would become prevalent, and the fees would remain.
| Humans are humans, taking away the password does not insulate
| them from their own basic nature.
|
| > - we have our personal information stolen because others
| chose weak passwords
|
| It's the same issue as above. Your information has value, so
| it will be sought out by people who wish to exploit it.
| Social engineering exists and won't go away just because we
| got rid of a single token based mechanism.
|
| > Given how much we suffer from other peoples' poor choices,
|
| It's a poor choice to be dependent on email or to give your
| personal information away to every single form that asks for
| it. You can balk at the external factors if you like, but you
| won't solve anything by it.
| hinkley wrote:
| I think they're talking about social interactions leading
| to exchange of personal information, and so a private
| person is still known by the ripples they leave in their
| social circles.
|
| For instance if grandma wishes me happy birthday, and she
| gets hacked, now they know my birthday. Grandma also
| probably gave away my mother's maiden name as well.
| novok wrote:
| It costs the company in support costs to deal with lockouts,
| and the newbie does want their cake and to eat it to, thus the
| entire push to passkeys.
| Dalewyn wrote:
| Hard agree.
|
| I can count on one hand the services that are critically
| important enough to warrant unique passwords and good practices
| anyway.
|
| All the other services I have accounts for? I literally can't
| care if some yahoo in WhereTheHellistan wants to and does get
| in, there's nothing valuable in there. They all get the same,
| simple, short password because that's the value of the things
| behind the password.
|
| Yes, this means all of you reading this are quite welcome to
| try and steal this HN account guarded by the same, simple,
| short password. I don't care, all you'll be getting are
| worthless shitposts and things of similar value in any other
| services you can find and breach with the same credentials.
| belinder wrote:
| If you want api keys to replace passwords then users need a built
| in mechanism on their device that stores it, since the majority
| of people are not going to be able to or want to copy some long
| obscure token and store it somewhere for later access. Some
| devices already have password managers and similar mechanisms
| built in, but it needs to be universally implemented and accepted
| before you could do something like this. Then there's still the
| question on do you share the api keys across devices?
| Pxtl wrote:
| Yes. Like I know people that have 100% bought-in to a single
| architecture -- all Google or all Apple -- who use the
| suggested random passwords built into the cross-platform-
| browsers of these platforms. But if you're not a single-
| platform cloud-account all the things person it's much more
| difficult.
| j45 wrote:
| Learning safe passwording is now a life skill.
|
| As or more important as house keys
| NelsonMinar wrote:
| I like this article because it forces us to recognize what secure
| users are really doing already. I haven't created my own password
| for something in ~8 years, since I started using LastPass and
| 1Password. I have no idea what my password is on any site, never
| see it, can't even type it on a keyboard reliably.
|
| Looking forward to them being replaced with passkeys.
| iambateman wrote:
| Login PIN by email is a much better pattern along the same lines.
| Forcing a specific, impossible to remember string on the user is
| weirdly hostile.
|
| If you want to avoid a password, just email the user a PIN every
| time they need to login. This works great for apps which don't
| need high security.
| causality0 wrote:
| I'm not going to use your service if I can't set my own password
| and be the one to decide if it needs more than just a password.
| The services I spend most of my time on and have vulnerable data
| on use 2FA, but the _majority_ of my accounts do not. My accounts
| for downloading Super Mario 64 romhacks or posting comments about
| barbecue recipes aren 't going to get entries on my Authenticator
| app nor do they deserve one.
| tenebrisalietum wrote:
| If you know what the user's password is, then you could
| potentially be liable for an improper access. This liability is
| is impossible if you have no way of knowing what that password
| might be, even if things you do know like 2FA codes are used with
| something only the user would know.
| 38 wrote:
| > Rather than allowing a user to set their own password,
| passwords can be issued in exactly the same way as API keys are
| now: a high-entropy password is randomly generated by the issuing
| website, and the user is shown the password once only and asked
| to record it. If the password is lost, a new password must be
| generated using the same process. The user cannot choose their
| password, but can get a new randomly generated one in the event
| of compromise. The password essentially becomes indistinguishable
| from an API key.
|
| GitHub does this now. you cannot push with your normal password,
| only a Personal Access Token. I am fine with this, but perhaps
| the process of setting and getting the token could be
| streamlined. Currently, you have to:
|
| 1. click profile
|
| 2. click settings
|
| 3. click developer settings (the last item of 24 items)
|
| 4. click personal access tokens (again the last item in the list)
|
| 5. click tokens classic (again the last item)
|
| 6. click generate new token
|
| 7. click generate new token (classic)
|
| 8. enter password
|
| 9. click confirm
|
| 10. enter note
|
| 11. choose expiration
|
| 12. choose scope
|
| 13. click generate token
|
| thats just way, way too many steps for the average user.
| crote wrote:
| Personal Access Tokens are intended for fully automated access,
| such as a deployment pipeline. They are not intended for daily
| use, and step 4 even explicitly says "Need an API token for
| scripts or testing?".
|
| For regular pushing you are expected to use a SSH key, and
| those are far easier to add.
| seabass-labrax wrote:
| Indeed, but you still need a Personal Access Token to
| integrate pull requests and issues with your Git client.
| GitHub doesn't support SSH authentication in those cases.
| ghusto wrote:
| By git client, do you mean something other than git?
| Something like a CI system? Even there you can use an SSH
| key?
| tagamma wrote:
| I think they mean a desktop GUI application on top of git
| like GitKraken or SourceTree. These sometimes allow you
| to perform actions like creating a PR (which is not done
| via git itself, of course).
| brasic wrote:
| (Nitpick) The preferred way for apps like this to work is
| a pseudo-OAuth flow which yields a token that is not a
| Personal Access Token. More ergonomic and better
| attribution to the application, which "owns" those
| requests.
| fieryskiff11 wrote:
| GitHub is a development platform, heavily related to tech
| though. People that are experienced enough to do git push can
| definitely manage API key-like passwords. This solution is not
| exactly suitable for any other industry, its literally a call
| for bankruptcy (unless you are B2B, and even with that, so many
| tickets, support overload...)
| seabass-labrax wrote:
| 99% of their users, even 99.99% might be programmers, but I
| was involved with a project where most of the contributors
| were lawyers. Most of them could only use the GitHub web
| interface ('edit file', not even the VS Code one) to make
| changes, so making it easier for them to use git push would
| be advantageous for everyone involved.
| charrondev wrote:
| I don't push with any access token, I push with SSH keys.
|
| An alternative IIRC is to a UI client like GitHub Desktop which
| lets you login/SSO everything like that, although I'm not sure
| if that only works because my SSH credentials are configured.
| seabass-labrax wrote:
| This article is the very embodiment of how I think about
| authentication! I once tried explaining to a top-brass security
| professional at Microsoft why mandatory, SMS-based '2FA' wouldn't
| be an improvement over simple passwords - they just didn't get
| it. I wish I could have shown them this essay.
|
| Legitimising 'Risk-Based Authentication' as a strategy is a big
| mistake in the software industry. It allows criminals to sit on
| compromised credentials, trying different combinations of
| accounts, user-agents and IP addresses until they get the
| jackpot: a website decides this time that there is 'low risk' to
| the login attempt, and the bad actors are in. When you make
| security-critical decisions with statistics (in this case,
| whether to permit a login attempt), you are essentially
| guaranteeing that there will be a certain proportion of breaches,
| because you set the risk threshold!
|
| Our efforts as an industry should be in making sure that
| credentials are not stolen in the first place: better and more
| widespread encryption, phishing resistance (with UX that supports
| that) and low-level security audits of encryption software and
| hardware are just a few of the areas where research and
| development would be valuable.
| razorfen wrote:
| > phishing resistance (with UX that supports that) and low-
| level security audits of encryption software and hardware
|
| Pardon my ignorance, but isn't this saying "we can't rely on
| reducing the likelihood of breaches, we should focus on
| reducing the likelihood of breaches"? Your recommendations are
| no more deterministic than the methods you eschew.
| seabass-labrax wrote:
| True, but "user secrets stolen, game over" is a much more
| healthy starting point than "user secrets stolen, well, maybe
| we can let criminals use only 10% of them by making login
| attempts more difficult". The latter means you can say "we
| reduced malicious logins by 90%" when what you are really
| doing is reducing _all unusual_ logins by 90%. It 's true
| that security audits don't guarantee success, but that
| percentage likelihood of security improvement comes at no
| cost to usability.
| s-xyz wrote:
| I am not an expert on the matter, but it feels like the same
| concept as Passkeys.
| unboxingelf wrote:
| this is effectively how nostr works. you generate a
| public/private keypair. the keys are bech32 encoded.
|
| https://github.com/nostr-protocol/nips/blob/master/19.md
| lolinder wrote:
| > Often this will be combined with fallacious notions such as
| "remember this device", the idea being you only have to go
| through all this the first time when logging in from a particular
| device. This idea is fallacious because the web has no notion of
| a "device", and this is a very intentional design choice made for
| privacy purposes. We are literally living through the gradual
| phase-out of third-party cookies, amongst other functionality,
| specifically to try and prevent this sort of thing, so why do web
| developers persist in believing in this fiction of a "device"? My
| own browser erases all cookies from an origin immediately after
| the last tab from that origin is closed, so these sites are
| convinced I am logging in from a new "device" every single time,
| and then demand I respond to one of these challenge emails.
|
| The phasing out of third-party cookies has nothing to do with the
| "remember this device" functionality, because those are almost
| always powered by first-party cookies, which are _not_ being
| phased out.
|
| The author has configured their browser to throw away cookies
| when the last tab closes, and that's their prerogative, but
| anyone who is savvy enough to configure that setting is also
| savvy enough to understand that that will break "remember this
| device". For everyone else, that phrasing is a perfectly
| reasonable abstraction on what is actually happening.
| brasic wrote:
| "Please read my rant about how this useless hair-shirt I wear
| to clear first party cookies too often breaks the web (for me)"
| > the web has no notion of a "device", and this is a very
| intentional design choice made for privacy purposes [...] why
| do web developers persist in believing in this fiction of a
| "device"?
|
| Cookies are a core part of the web which enable the
| construction of stateful applications on top of a stateless
| protocol. "Remembered device" is usually just an extra cookie
| set on login, or a row in a backend database. It's no more
| fictional than the web itself, which is after all just a series
| of electrical impulses over wires.
|
| Whether a device (however you build that abstraction) has
| previously logged in is a high-signal data point that
| meaningfully increases account security at login time and all
| serious web security teams use it to protect their users.
| [deleted]
| starttoaster wrote:
| It seems to me like the user you're replying to is well aware
| of how web devs attempt to identify unique devices (browser
| cookies.) They're saying that the manner that this is
| implemented leads to poor user experiences due to the faulty
| assumption that just because a cookie doesn't exist in the
| client browser, that the device is in fact unique to
| previously used devices. Which I don't see how your comment
| actually addresses. I tend to agree with the other user.
| Making healthy security conscious decisions like low TTLs on
| local cookie storage (such as cookie purge on browser/tab
| close) feels unrewarded when the site enforces additional
| security gates on login. The point is: unique login devices
| may have been a good idea, but in practice the design of the
| web does not make them an ideal candidate for bolstering user
| security. Maybe someday passkeys solves the unique device
| problem sufficiently such that faulty assumption methods like
| browser cookie storage cease to be commonplace.
| lolinder wrote:
| I'm the parent commenter, but the viewpoint you're agreeing
| with is an extract from the article, not my perspective, as
| indicated by the > before the paragraph. My own comments
| are the subsequent two paragraphs.
|
| In short, I entirely agree with @brasic: the article author
| has a nonstandard configuration (clearing cookies
| automatically before their expiry date) and based their
| entire article on the difficulties that this highly unusual
| and unnecessary choice has caused for them. "Hair shirt" is
| a great way to describe it.
|
| > Making healthy security conscious decisions like low TTLs
| on local cookie storage (such as cookie purge on
| browser/tab close) feels unrewarded when the site enforces
| additional security gates on login. The point is: unique
| login devices may have been a good idea, but in practice
| the design of the web does not make them an ideal candidate
| for bolstering user security.
|
| This is exactly @brasic's point, though: if a website can
| affirmatively identify that you've logged in from this
| machine before, that's a pretty good indicator that this
| new session is a legitimate login. We _can_ do that through
| cookies, and for most users that 's just fine. If you clear
| cookies regularly for security reasons, then you shouldn't
| be offended that a website asks you for extra confirmation
| that you are you, since that is _also_ done for security
| reasons.
|
| Clearing cookies for a domain is instructing your browser
| to identify itself as though it had never spoken to that
| server before. If you want the server to know you're still
| you, maybe just leave the cookies there?
| brasic wrote:
| Yep, to be clear I was agreeing with lolinder. I would
| have posted top level but they had already expressed
| almost exactly my objection to the article so I replied
| to avoid redundancy.
| rjh29 wrote:
| Thank you for teaching me the word hair-shirt. These kind of
| blog posts come up often on HN and it's good to have a word
| to describe them.
| wizofaus wrote:
| I thought "remember this device" more typically worked via a
| combination of browser fingerprinting (which can be pretty
| sophisticated, e.g. even relying on rendering behaviours) and
| local storage, which may or may not involve cookies.
| anderspitman wrote:
| I read OP's mention of third party cookies as an example of
| browsers supposedly moving in a more privacy focused direction,
| not as being related to authentication.
| [deleted]
| lolinder wrote:
| Well, the weird thing about the phrasing is the claim that
| third-party cookies are being phased out to "prevent this
| sort of thing"--where "this sort of thing" is "remember this
| device".
|
| This is... sorta true? Insofar as creepy advertisers _also_
| "remember this device". But a first-party site storing a
| cookie to remember a login session is not at all in the same
| category for me.
| ozim wrote:
| Author is wrong in many ways.
|
| All post reads like Dunning-Kruger case, he seems to know quite
| some stuff but also misses 3rd party cookies. Overly focuses on
| weak passwords completely skipping password leaks or just
| mentioning password reuse.
|
| Ignoring that TOTP is actually decent interface for getting non
| technical and not caring at all users use random high entropy
| secrets. Getting regular people to keep some generated random
| strings won't work.
|
| In the end ignoring all experience of industry which is:
|
| leaked passwords and email lists can be used in password
| spraying attacks where specific user is not targeted it is just
| opportunistic low hanging fruit automated exploitation.
|
| Then those easy exploitable accounts in services can be used to
| ask connected users for loans or financial help as a scam.
| londons_explore wrote:
| I kinda wish there was something like cookies, but even more
| persistent. Lets call them permacookies.
|
| I want to "remember my device", and have that keep me logged in
| forever with a permacookie. I don't even want to have a
| username and password. I want to create an account and be
| forever logged in.
|
| There would be mechanisms to backup my permacookies, or
| transfer them to other devices. I'd have control of which sites
| could set permacookies for when I didn't want to be tracked
| too.
| hanniabu wrote:
| And then the credentials get stolen through phishing
| hkt wrote:
| The idea with client certificates is that they'll live in a
| secure keychain and never leave it. The API exposed by
| whatever manages them will expose functions of the key
| (authenticate, encrypt) but not the key itself. If the
| implementation is decent, you'll authenticate every
| request, so it isn't possible for requests to be forged or
| credentials stolen unless you've got a vector to attack the
| OS's keychain.
| ozim wrote:
| Webauthn should allow use of private key authentication
| stored on external hardware key or in device.
|
| You really want support for key authentication just like ssh.
|
| You shouldn't move private keys between devices, you should
| have easy way to add new public keys to a service when you
| setu new device.
|
| Problem is permacookies or private keys don't really allow
| ad-hoc access but maybe nowadays people don't need to login
| to their accounts from cyber cafes :)
| Pxtl wrote:
| I saw this pattern done on a forum. You just provided your
| email, and it would set a super-long-lived cookie. There was
| a button for "recreate my cookie" which sent you an email -
| like a password reset function without a password.
|
| It was surprising the first time I used it but now I wish
| everything that didn't handle cash worked that way.
| axelthegerman wrote:
| How about local storage? Only downside is that this data
| isn't sent automatically on ever request (unlike cookies). It
| would be possible though to send this secret from local
| storage via a separate request and receive a session cookie
| that then let's you be logged in automatically
| hinkley wrote:
| Maybe shared local storage should be a browser standard.
| Let me keep track of my own data, but also share it with my
| tablet and phone by clicking a bunch of buttons.
| danShumway wrote:
| This is circling around Native File Access, which is
| absolutely something the web needs and if handled
| correctly would be a huge improvement for user privacy
| and user autonomy. It would open the door for fully
| offline webapps with no accounts or serverside
| components, with much better sandboxing than native apps,
| and with full user control over app data using just a
| file browser. And it would allow for app data that could
| be easily shared between apps when necessary without
| compromising user privacy or security because the app
| data would just be a directory with files.
|
| BUT... the problem is that if handled _incorrectly_ it
| would be a disaster for web security, would open up tons
| of holes for user tracking and data theft, and would
| basically be a horror show. There are a dozen things that
| could go wrong with the spec, and all of them would be
| _serious_ problems if they did go wrong.
|
| And Chrome is heavily involved in the spec. So it's a
| tough position to be in to try and figure out whether
| it's worth advocating for. Mozilla currently considers
| native filesystem access to be harmful, and I don't know
| whether or not I agree with them. I wish Mozilla would
| propose an alternative spec developed entirely internally
| without interaction from Google.
| thelastparadise wrote:
| Even better: shared storage where every website has
| access to the same storage data.
|
| Log in once, on one website, then be logged in on all
| websites forever.
| hinkley wrote:
| Isn't that basically third party cookies all over again?
|
| If you work for advertisers this sounds like a great
| idea. Better than eating babies.
| kmeisthax wrote:
| This is what HTTP auth headers are for, but the UX for using
| header authentication on modern browsers is utter garbage.
| There's no way to present a themed login form, no way to log
| the user out _at all_ , and all sorts of weird papercut
| bugs[0] in between.
|
| [0] My favorite: opening DevTools triggers a second
| credential prompt because the DevTools session wants to
| download some mapfiles or something. No infrastructure exists
| to make that HTTP request in the context of the current tab,
| apparently.
| codazoda wrote:
| I wish there was better browser support for this but I
| still use it for pet projects. Last year I wrote about why
| I'm still using HTTP Basic Auth.
|
| https://joeldare.com/why-im-using-http-basic-auth-in-2022
| simfree wrote:
| Safari on iOS does not play nice with Basic Auth. No
| credential saving, re-promting you for credentials on
| each page you navigate to.
|
| non-iOS browsers seem to handle HTTP basic auth
| gracefully.
| freeone3000 wrote:
| You can log the user out by changing the "realm" parameter,
| which is a freeform string and can be quite long. As well,
| setting realm will cause devtools to use cached credentials
| similar to a new tab.
|
| "No themed login form" oh no! Anyway. (I really think that
| the "theming" on login and sign-up forms breaches which
| bits are done by the browser and which bits are not. We've
| had to kludge back support)
| fireflash38 wrote:
| Know what my favorite part of the whole modern auth is? The
| most "reliable and secure" way to enter and transmit
| credentials is the browser. You know, that thing that has
| had absolutely tons of footguns with XSS problems, terrible
| cookie management/stealing, and generally leaving things up
| to websites to do auth.
|
| They're even deprecating auth via non-browser means in
| newer OAuth/GNAP standards. It's like they're designing
| around what things are _now_ , rather than thinking ahead
| as to what would be best. Like rather than website -
| managed auth, it be fully browser controlled (not HTML
| forms). Not cookies, but something prescribed by the
| browser (or whatever other application you might use,
| rather than needing to embed a browser yet again in
| everything).
| ec109685 wrote:
| That's what Passkeys are supposed to do. You have an identity
| tied to that website, shared across all your devices.
| danShumway wrote:
| I'm sure I'm missing something, but... isn't that cookies?
|
| I think expiration fields on cookies are optional (correct me
| if I'm wrong), you just can't rely on them sticking around
| because the user might clear them (I'd have control of which
| sites could set permacookies for when I didn't want to be
| tracked too). Which is honestly desired behavior, I'm
| assuming you would want the ability to delete a permacookie.
|
| Cookies _can 't_ be synced through Firefox sync (I thought
| they could but just checked and my bad, they can't) -- but
| there's nothing preventing browser sync from handling that,
| and Firefox sync is E2EE so it would as secure as any other
| transfer method. It wouldn't be too hard to build a browser
| extension to allow exporting them or importing them manually;
| cookies are just text content so they're trivial to inspect
| and manipulate and even manually copy and paste into new
| browsers through the dev tools.
|
| As a login mechanism, having a permacookie is somewhat
| insecure so most sites use expiration dates. I'm sympathetic
| to the desire to be able to override that, but... the
| mechanisms most sites use are things like signed tokens with
| expiration dates checked serverside, so there's not much a
| browser can do about blocking a website from doing that.
| Short of using stateless key-based authentication I'm not
| sure how it would be technically possible to get rid of that
| behavior.
|
| ----
|
| I'm being a little bit disingenuous here in the sense that...
| yeah I want native file access too. I understand that cookies
| are not the same as native file access and the controls
| aren't really the same. But that's a much larger conversation
| with much larger scope and with more implications for browser
| security.
|
| But if you're talking specifically about login, it does seem
| like cookies are mostly doing everything you want and your
| bigger problem is just that websites time-out logins? And
| that Firefox sync doesn't currently sync them, which... an
| extension could handle that.
|
| What is the non-permanent part of a cookie, is it just that
| user controls for clearing cookies aren't granular enough and
| they're too easy for the user to accidentally delete?
|
| I guess mobile too, iOS safari will clear localstorage
| sometimes. That's a very real issue (and a big reason why I
| want native file access), but it's less of an issue for login
| since occasionally losing your login permacookie isn't a big
| deal, it's only a big deal if you lose offline serverless
| webapp data.
| bobbylarrybobby wrote:
| Passkeys?
| amadeuspagel wrote:
| The max age of a cookie is a little more then a year, meaning
| that as long as you visit a site more then once per year,
| this is possible.
| charcircuit wrote:
| Coookies can live longer than a year. Making it no longer
| possible to make them "permanent" is a browser specific
| thing.
| hinkley wrote:
| Pulling on this thread a bit, when I get a new set top box,
| most of the apps have a url or a QR code you can use to copy
| your session to a new machine. You could just do that for all
| machines and have no cookies at all. iOS even has some ways
| to make that a bit easier.
|
| For some apps this would suffice. But for apps we use to live
| our lives, what do you do when someone has no access to their
| devices and they need to log in to a fresh device? Some apps
| will need passwords, or some other mechanism to prove you are
| who you say you are. But then you can leverage those apps to
| get back into your other apps in the case of, say, a fire.
| jaredhallen wrote:
| Sounds like certificates. You can use ssh this way, for
| example.
| justsomeadvice0 wrote:
| You can use mTLS client certificates (kept in the system
| key store) in browsers this way; but the UX is pretty hard
| to get right, and certificates nearly always have to have
| an expiry date to deal with the compromise-able nature of
| keys imported into the system key store.
| fooker wrote:
| >There would be mechanisms to backup my permacookies, or
| transfer them to other devices.
|
| There would also be intentional and unintentional mechanisms
| for stealing these permacookies.
| ballenf wrote:
| Password managers could take over and manage cookie
| storage/retrieval.
|
| Or browsers could treat cookies more like passwords and have
| a user-controllable flow on each new session: "Here's this
| site's cookies from your last session, do you want to place
| these back in the browser storage?"
|
| The fundamental issue is that browser cookies and password
| managers have an overlap in their usage domain.
| kwhitefoot wrote:
| Firefox remembers my passwords for me already. Why would I
| need an extra tool to do it? And so does Android.
| bazzargh wrote:
| not all of my passwords are for browser-based services,
| not all of my secrets are passwords, and I have several
| devices with different operating systems.
|
| (eg, my password manager includes github recovery tokens,
| ssh keys and passphrases, recovery questions, my tax and
| health service identifiers, wifi passwords and the admin
| passwords)
| zuppy wrote:
| we already do have that and needs no certificates or other
| complex things for the end user:
| https://developer.mozilla.org/en-
| US/docs/Web/API/Window/loca...
|
| is it secure? hell no, but it can be used.
| hinkley wrote:
| [citation needed] on local storage being more durable than
| cookies.
| novok wrote:
| Many websites and apps can do this, but explicitly do not in
| the interest of 'security' and 'anti-fraud'. Discord is a
| pretty bad offender of this.
| NoMoreNicksLeft wrote:
| Isn't such a thing called a crypto key? And if you had such a
| thing, why in the hell would anyone sensible ever use browser
| cookie functionality to store that?
|
| Learn to use a password manager.
| hkt wrote:
| What you're looking for is client certificates. This has
| existed for years but webby people think users are too stupid
| to use them, so we get the menagerie of half baked trash we
| have now instead.
| pierat wrote:
| Client cert handing at the load balancer level and reverse
| proxy level are stupid hard to get right.
|
| I would burn client certs to the ground if I could.
| sublinear wrote:
| > What you're looking for is client certificates.
|
| I agree with this, but...
|
| > users are too stupid to use them
|
| they are. Key management is not trivial.
| SoftTalker wrote:
| Yes, if you've ever managed a shared unix system that
| uses ssh keys for login, you know that a large fraction
| of users cannot manage them.
|
| Among the steps of generating a key pair, getting the
| public key (not the private one) into their
| authorized_keys file (which is in a hidden directory, for
| pete's sake) without introducing any extra characters or
| line breaks or getting the wrong permissions on the file,
| getting their ssh client programs to use the proper
| private key for the host they are trying to log in to, or
| figuring out ssh-agent, there are just way too many
| opportunities to screw up or get confused.
| hkt wrote:
| It seems a little bit uncharitable to assume the UX on
| client certs has to be as bad as the UX on SSH keys,
| although I'll concede the point that historically it has
| been.
| hinkley wrote:
| When I worked on a code signing app, I had front row
| seats to how magical everyone thinks certificates are. It
| took me several years to convince the group that they
| aren't that complicated.
|
| I think the world would be a better place if LetsEncrypt
| had come into being about five years earlier.
| drdaeman wrote:
| It's a myth, they are not. They are uneducated and lazy1,
| not stupid.
|
| Save for minorities with genuine learning disorders,
| people can learn how to click/tap a bunch of buttons in a
| sequence. They aren't running a PKI (that's on
| platform/browser vendor), they are just picking an
| identity from the list after all. They learn how to click
| the right buttons all the time, as UI designers' managers
| decide it's time for a new bonus and swing things around
| with a "new graphic language".
|
| Basic certificate management (from end-user perspective)
| is not harder than password management. Passkeys are
| conceptually the exact same thing2 as TLS client
| certificates, just without a purposefully neglected UI
| and a DIY attitude3 (TLS is supported by nearly anything,
| barely anything knows about WebAuthn JS shenanigans).
|
| 1) Not in a bad way. "Lazy" as in "lazy evaluation", not
| "lazy ass". Maybe there's a better word for this.
|
| 2) Save for some technical details, both are essentially
| keypair management.
|
| 3) There is almost no UI, it's just an API then all the
| visual bits are left out as an exercise to individual app
| designers (partially on platform/browser developers,
| partially on website developers). Browser vendors just
| hated those areas because they weren't deemed cool and
| fancy ([un]like some JS framework of the day) and shoved
| them under the rug as deep as they could. And unlike TLS,
| there is no standard how to pass data around, everyone
| invents their own `POST /login/webauthn` semantics.
| notpushkin wrote:
| So, like Passkeys / WebAuthn?
| QhwyF3AxE wrote:
| passkeys is a common noun (like the word "password") and
| therefore should always be lowercase unless it's the first
| word in the sentence.
| simonw wrote:
| Honestly that feels like what apps are. One of the most
| compelling reasons to install an iOS app for something like
| an online bank is so that I won't have to worry about my
| cookies expiring and forcing me to login again.
| ballenf wrote:
| But then there are apps like Discord which log you out of
| the app if you don't use it for X days.
| SoftTalker wrote:
| My banking app makes me log in every time. I prefer that,
| but I didn't realize some apps don't do that?
| Kwpolska wrote:
| My banking apps ask only for my fingerprint, or a short
| PIN if biometrics are not available. You could call that
| "logging in", but it's certainly not as serious of a log-
| in as you would have on the web (with a username and a
| password, and if the computer is unrecognized,
| authentication on the phone).
| nucleardog wrote:
| Most of mine do too so I don't use them.
|
| Either I use a short, easy to type password for my
| banking so I can log in all the time, or I use a long one
| and use a password manager to fill it for me and we're
| basically back to "use the phone's biometric
| authentication" with extra steps.
|
| There's already a strong, secure option for
| authenticating the user on a mobile device... I wish
| everyone would use it instead of trying to use the crap
| option we're using elsewhere, especially since passwords
| are a pain on a tiny touchscreen keyboard.
| alistairSH wrote:
| You don't force login on your banking apps? Eek. Or maybe
| you mean they do biometric auth instead of user/pwd?
| Leaving banking/finance apps unprotected sounds sketchy AF
| to me.
| londons_explore wrote:
| I hate the fact that if you lose your phone and restore to
| a new one, suddenly every app is logged out again.
|
| Like can't the login-state be part of the backup? If I was
| logged in when the backup was taken, I should still be
| logged in when restored to a new device.
| Tagbert wrote:
| On iOS many (most?) apps do store your credentials in a
| way that you don't have to login if you have restored
| from backup or setup a new device from backup. Not all do
| this. Google is one annoying example that requires a
| fresh authentication.
| iknowstuff wrote:
| I think if you do an encrypted itunes backup to your mac,
| they should remain signed in
| samwillis wrote:
| This is why I hope PWAs take off more. If there is an
| implicit "save first party cookies forever" for PWAs that
| have been "installed" and we make them discoverable it's a
| net win.
| londons_explore wrote:
| Apple will make sure PWA's aren't successful. They can't
| risk their control over the app ecosystem.
| j5155 wrote:
| Are you aware that iOS supports PWAs, and recently
| implemented notifications for them?
| samwillis wrote:
| Exactly, they are in recent years moving to address these
| previous issues, I applaud them.
|
| I would like it if they were more discoverable, but not
| necessarily with the obnoxious pop ups. It would be
| awesome if they let you list a PWA in the App Store for a
| fee or the 30% cut.
| londons_explore wrote:
| Only 8 years late:
| https://developer.chrome.com/blog/push-notifications-on-
| the-...
|
| Besides - there are plenty of other things Apple can do
| to ensure PWA's don't take off. For example, there is no
| ability for a web-app to have a "click here to install to
| desktop" button - the website must try to guide the user
| into clicking the share button and then creating a
| desktop icon - which most users don't associate with
| 'installing' something.
|
| Also, the 50Mb limit on PWA's prevents a lot of usecases
| - like photo/video editors, and even most messaging apps.
| guraf wrote:
| Fascinating how to keep moving the goalposts.
|
| Firefox refuses to implement pwa. Chrome has pwas but
| they're not isolated.
|
| Apple is the only one with sane pwa but somehow they're
| the worst and are totally sabotaging PWAs because
| something something walled garden?
| [deleted]
| simfree wrote:
| Firefox Android certainly supports Progressive Web Apps
| with push notifications, I use them daily.
| jefftk wrote:
| If you want to use a PWA on an iPhone, you are fully
| dependent on Safari support. Firefox's decisions here
| aren't blocking anyone.
| andai wrote:
| >50 MB excludes most messaging apps
|
| The entirety of TempleOS (including dozens of programs
| and multimedia games) is 2MB.
| londons_explore wrote:
| This isn't just the limit for css/js... It's the limit
| for user data too. Ie. if you share some videos with a
| PWA app, then all the videos have to fit inside 50MB
| unless you want to fetch them from a server each time you
| play them.
|
| Or consider a PWA music player - 50MB of music is all you
| can play offline.
|
| Or a photo editor - 50MB is the limit for all your saved
| files unless you want to save them to a cloud server.
| jefftk wrote:
| At 640x480 (for the whole screen) and 16-bit color
| philistine wrote:
| Hey, TempleOS is simply using the resolution God
| requires.
| troupo wrote:
| > Honestly that feels like what apps are.
|
| Almost every single app on my phone forgets who I am even
| after minor updates.
|
| Apps I use infrequently? It's like they never knew me to
| begin with.
| [deleted]
| Brian_K_White wrote:
| I think SQRL does this. But since no one can own it or sell
| it, it will never be adopted by anything that matters.
| Modified3019 wrote:
| That basically sounds like what yubikey's and the like try to
| do.
| seiferteric wrote:
| Might as well use client certificates at that point. Along
| with TFA, if we don't have users choose passwords, then just
| issue a client cert and have it installed in the browser,
| would probably require some new web standard.
| CoastalCoder wrote:
| > I kinda wish there was something like cookies, but even
| more persistent.
|
| Fruitcakes.
| waynesonfire wrote:
| I dont agree with you that it's the user's fault. The issue
| isn't understanding of remember this device feature. The issue
| is it's a fundamentally broken design. One, because users have
| multiple devices and second, the feature is crippled when
| employing privacy preserving behavior.
|
| I should be able to authenticate by proving access to a device
| such as a yubikey, as an example. Now, the site can properly
| remember the user. This missing feature is the fault of crummy
| UX, not the user.
| hinkley wrote:
| When I think 'multiple devices' I think 'multiple devices'.
| Yubikey is a solution for multiple _computers_ but I don 't
| see how something 'such as a yubikey' solves this problem for
| _devices_.
| littlestymaar wrote:
| The author is Hugo Landau, so of course it is a bad take, how
| else could it be. The real question at this point is why his
| terrible takes reach the front page every two weeks...
| robobro wrote:
| > My own browser erases all cookies from an origin immediately
| after the last tab from that origin is closed,
|
| Sounds like a you problem, dude. You have to go out of your way
| to force this behavior with any mainstream browser.
| ricree wrote:
| The text you're replying to is part of a long quote from the
| linked article, not a statement by the person you replied to.
| Ferret7446 wrote:
| > anyone who is savvy enough to configure that setting is also
| savvy enough to understand that that will break "remember this
| device"
|
| I don't think so. Most people who understand that that will
| break "remember this device" also understand that clearing
| cookies doesn't help much with privacy. So the people who do
| enable that setting generally only know that cookies ==
| tracking and do not understand that that will break "remember
| this device" ("Dunning-Kruger").
| hinkley wrote:
| Yeah I don't think he has adequately explored what happens when
| the website gives him a giant token to enter and then it can't
| be stored in a cookie. What does he think is going to happen
| next?
| [deleted]
| knodi123 wrote:
| He's right that it's a him problem- but my bank and my HR
| website both have "Remember this device" placebo checkboxes
| that do absolutely nothing. The feature is broken way too often
| even on stock browsers.
| khromov wrote:
| Great post, I came to much the same conclusion when building my
| app - a secure token is generated on account creation and users
| are encouraged to save it in case the need to restore their
| account. I blogged about the implementation below together with
| how the UI looks (under the "Authentication" heading):
| https://khromov.se/building-a-privacy-friendly-self-hosted-a...
| gumby wrote:
| Hmm, do I set my own password?
|
| From the web site's POV I certainly do.
|
| But my password manager generates the password and remembers it
| for me and I only ever see it if the generated one somehow
| violates the site's arcane password rules and thus requires a bit
| of manual manipulation. Which rarely happens.
| simias wrote:
| I think there are two approaches to the issue:
|
| - You consider that the user getting their account pwnd is their
| problem. Let them set their password. That includes things like
| forums and other websites where an user losing their account is
| not critical and you can easily just tell them "too bad, use a
| better password next time" if something goes wrong.
|
| - You consider that the user getting their account pwnd is going
| to be your problem. You're a bank, or some paid service for
| instance, and the user will ask for support if they lose access
| to their account. In this case it 100% makes sense to force a
| password on the user to prevent them from selecting something
| stupid IMO.
| two_handfuls wrote:
| The problem with cookies (and "remember this device") is that the
| same mechanism is used for remembering things that help the user
| (that we are logged in) and things that harm the user (ads,
| tracking).
|
| Edit: I'm talking about first-party cookies.
| lolinder wrote:
| That's why we're in the process of phasing out _third-party_
| cookies but retaining _first-party_ cookies. It 's the closest
| dividing line we have for "good" and "bad" cookie applications:
| most good cookies are first-party (there are some use cases
| that are unfortunately caught in the crossfire) and most bad
| ones are third-party.
|
| Any time you give developers access to storage on the user
| device for _any_ reason, you 've given them a way to track
| users. First-party cookies are a decent compromise in my book:
| you can track users, but you can only track their movements on
| your own domain.
| two_handfuls wrote:
| I was talking about first-party cookies.
|
| Third-party cookies don't have this ambiguity, they're
| unequivocally bad.
| lolinder wrote:
| Ah. Well, as I noted, it's not a problem with the design of
| cookies, it would be a problem with _any_ storage mechanism
| that HTTP could possibly support.
|
| We _want_ apps to be able to store session IDs so that I
| don 't have to send my username/password with every single
| HTTP request. But as soon as I've given you permission to
| remember my session, you can use that to start tracking my
| movements on your site. There's no way around that.
|
| The only thing we could do is add a layer on top that
| prevents most sites from using cookies at all--make cookies
| a permission similar to camera and screen sharing. But
| first-party cookies aren't easy to use for abusive purposes
| and (as we all found out post-GDPR) popup fatigue is real,
| so I'm personally okay leaving them as is by default.
| Anyone who isn't comfortable with them can easily install
| extensions that implement more complex behaviors.
| madeofpalk wrote:
| This is basically exactly what WebAuthN/Passkeys is, right?
| krupan wrote:
| That's like saying: IPv6 is basically IPv4 with bigger
| addresses, right?
| sixstringtheory wrote:
| I wonder if "true multi factor" security requires exclusivity
| between each factor. So, you cannot "know" anything about the
| "thing you have". It should be more like a yubikey that you plug
| into your computer and which is secure enough that you cannot get
| the information out of it to "know" it. That's a little harder to
| do for the "thing you are" factor because we can't design a
| system to use a feature we can't understand. And maybe we
| shouldn't really "have" the thing we know, as in, it shouldn't be
| recorded in something we have. Of course that makes it easier to
| forget. But then again, I don't have my 1Password master password
| recorded anywhere. If I forget it, I'm pretty fucked.
|
| I've often considered moving that master password to the frontier
| of email access and just never recording a password and using
| password reset for every login session.
|
| Regarding API keys vs passwords, a difference is that API keys
| are something that are used on your behalf by automated systems,
| whereas passwords IME are always something you manually input at
| the time you need it.
| crote wrote:
| 100%. Storing your "2FA" TOTP tokens in your password manager
| is asking for trouble, in my opinion. Why put all your bags in
| one basket? The moment your PC gets owned your are pretty much
| _permanently_ locked out of _all_ your accounts.
| quectophoton wrote:
| I agree, but I'd point out one thing just in case you're
| using "PC" in a restrictive sense.
|
| There's no difference between using a big Personal Computer
| (PC) like a desktop computer, or a small Personal Computer
| (PC) like a smartphone. Both are something you have.
|
| The problem is not that a bigger computer that never leaves
| your home is more insecure and that the small computer with a
| touch screen that actually leaves your home is more secure.
|
| The problem is also not storing TOTP in a password manager.
| Because a password manager can also be used from a smartphone
| and a TOTP authenticator can also be used from a desktop
| computer.
|
| The problem is using the same device ("factor", if we're
| being fancy) for storing and reading both secrets, because
| that means if the device is compromised it'll be able to read
| both types of secrets.
|
| So using a desktop computer for passwords and a smartphone
| for TOTP, should be just as fine as using a laptop 1 for
| passwords and a laptop 2 for TOTP.
| kortex wrote:
| I'm way more at risk of locking myself out than someone
| getting onto my system, getting into my password store,
| exporting secrets, and using them to ruin my life. Honestly
| it would probably make national news if someone physically
| burgled their digital identity.
| exabrial wrote:
| In a corporate environment, it makes absolutely zero sense to let
| users pick their passwords.
|
| They will simple use the same login as their tamagotchi pet.
| [deleted]
| haunter wrote:
| I play a japanese gacha game and there is no password there for
| your account. If you want to login they send you a code to your
| email and then you use that (valid for 30 seconds). I'm not a
| security expert but I always liked that for some reason
| HoppyHaus wrote:
| Those are called "magic links"
| crote wrote:
| The problem is that email is not guaranteed to arrive in 30
| seconds. Speaking from experience, it is _extremely_
| frustrating trying to access a resource and being unable to do
| so because someone in the entire email chain did a transient
| whoopsie.
| lolinder wrote:
| Yep. And it's often not solvable by just sending the email
| again: I've more than once found cases where an app's email
| provider is particularly slow and the tokens arrive late no
| matter how many times I send them.
|
| Bonus points if each email has a new token and only the most
| recent one is valid, because then you're stuck trying to
| remember how many times you clicked the "email me" button. Is
| this the right token, or am I waiting for one more to come
| in?
| weinzierl wrote:
| I use two services that do the same, so it is not completely
| uncommon. Both services don't require frequent login, though.
| One service is a DNS provider and the other a learning platform
| where the primary way of interaction doesn't require a login at
| their platform.
| rvz wrote:
| Just use passkeys. Then we can get rid of 'passwords', 'Forgot
| passwords', 'SMS 2FA', etc for good and make password breaches
| (not data breaches) a thing of the past.
| AndrewKemendo wrote:
| >The only discernible difference between TOTP and a site-
| generated password is in how knowledge of the secret is proven.
| With TOTP, knowledge of the secret is proven without sending it
| to the website. With a site-generated password, knowledge of the
| secret is proven by sending that secret to the website.
|
| The whole point of a passphrase is that IT DOESNT CHANGE HANDS
| EVER.
|
| The reality though is that computers subvert the system of
| passphrasing because the complexity required for passphrases
| within a computing systems is easy for computers to beat but hard
| for people to recall
|
| So you have a perfect situation where the historical context is
| maintained (person will remember their self-generated passphrase)
| but the system also can probably guess any passphrase that a
| human could remember without any additional tools
|
| So now, given that we REQUIRE more complexity than people can
| recall, we force people to use additional tools for
| creating/managing their passphrases which subvert the entire
| principle of a passphrase. Namely:
|
| IT DOESNT CHANGE HANDS EVER
|
| So the whole system is corrupted at it's root and there is no way
| to solve this problem with the current structure
| badrabbit wrote:
| I guess the author doesn't know but setting password for users
| used to be more common. They would put it on a sticky under their
| keyboard or something(i did it myself too and I was in IT at the
| time, didn't give a shit, getting locked out every other day was
| affecting my perfrormance/metrics).
|
| The latesr NIST guidline is goes further by eliminating password
| complexity and focusing memorable high-entropy passphrases. This
| is a "what you know" auth factor, even with password managers in
| play, the master password for that or for your high-impact sso
| password (work sso that can access everything) should ideally be
| stored only in your head.
|
| But if the author insists, users should be given printed password
| books and enable MFA.
| gerbilly wrote:
| Cos we want to be able to blame the users when there is a data
| breach. :-)
| varelse wrote:
| [dead]
| justsomeadvice0 wrote:
| A long time ago I wrote a variant of this - the signup page would
| generate a token, place it in a hidden password field, submit a
| hidden form, and instruct the user to click the "Save password"
| dialog in their browser. One advantage of this was e.g. Chrome
| would sync the password immediately across all your devices (in
| some ways this was a privacy violation, although one that the
| user had to explicitly opt themselves into). New sessions (e.g.,
| if you reset or lost your browser's stored passwords) still
| happened via email verification, though.
|
| Today I would just use passkeys.
| anderspitman wrote:
| This is interesting. I'm not sure how I feel about it from the
| perspective of the user understanding what they're consenting
| to, but it's secure and the flow is simple.
|
| I don't support passwords on any of my services. Emailed magic
| links and SSO are the encouraged methods, even with all the
| tradeoffs. I've considered allowing users to generate tokens
| similar to OP, but some percentage of them will be emailed
| around and pasted into phishing sites etc.
|
| But something like this could work as an option, especially if
| it could integrate with a couple popular password managers as
| well. Not sure if that's even possible.
| cushpush wrote:
| Password replacements are like septic systems, everyone needs one
| and nobody wants to do the work.
| upofadown wrote:
| For a login situation with extreme rate limiting (say 3 tries a
| day) "high entropy" might not involve a lot of randomness. A
| random 8 character password handed out to a user is overkill. Two
| random words is overkill. Heck, a single diceware word would take
| 7 years to guess in that environment. For 100 years you only need
| something like 4 base32 characters.
| codetrotter wrote:
| That's all fun and nice until someone decides to antagonise you
| and they intentionally make three failed login attempts for
| your username into the website every n hours, keeping you
| unable to sign into your account.
| upofadown wrote:
| I think that most people can come up with more effective ways
| to annoy someone.
| hollerith wrote:
| They do this to the accounts you use to communicate
| simultaneous with an attack on your reputation, i.e., when
| being able to to communicate suddenly becomes critical (for
| defending yourself against the allegations).
| sjadoinqwoeihad wrote:
| You can't ratelimit someone you have not yet identified. Unless
| their username is also a password. But then you just have 2
| passwords. And the ID password would have to be sufficiently
| high entropy to not be hit by bots.
| __ryan__ wrote:
| This isn't the attack vector to be concerned about. More
| concerning is when there's a data breach and an attacker gains
| access to hashed passwords. At that point, you attack the hash
| not the API.
|
| This comment is an example of why I wouldn't want any given
| website to choose my password.
| upofadown wrote:
| That assumes the situation where the password hashes are
| stored in a way that is less secure than the actual data that
| the attacker ultimately wants access to. That must not be a
| very common situation.
|
| The passwords will not be of any use on any other system.
| This would eliminate password reuse.
| __ryan__ wrote:
| Accessing a users data is not the only reason for hacking
| their account. Performing actions on behalf of a user is
| just as much of a threat.
|
| Edit: also, if an attacker dumps all the data today then
| loses access to the data tomorrow, having access to my
| password hashes means they can access my account and data
| later.
| KnobbleMcKnees wrote:
| The company I work for currently gave me my password, comprised
| of four space-separated words, on my first day. It has no expiry
| and can only be changed at request or if compromised.
|
| My only gripe with this approach is that my specific password is
| a bit awkward to type. I tend to pick passwords at least partly
| based on "keyboard feel" and it's annoying that there's one word
| that has a lot of repetition of colocated letters.
|
| Other than that it's a fantastic model and hugely preferred over
| routine password resets.
| felipeccastro wrote:
| This seems an interesting approach, if sufficiently safe for
| most cases. What if, when creating an account and choosing a
| password, the app enforced very long passwords but suggested a
| default, random one like in your example? This would have most
| of the benefits of the suggestion in the article (high entropy)
| while still not removing the choice of the user to pick their
| own preferred password.
|
| Does your company also use 2FA? I'd be curious to see if very
| long passwords are secure enough to not need the 2FA anymore,
| as most methods are annoying to the user.
| amelius wrote:
| > comprised of four space-separated words
|
| correct horse battery staple?
|
| https://www.explainxkcd.com/wiki/index.php/936:_Password_Str...
| amarshall wrote:
| > My own browser erases all cookies from an origin immediately
| after the last tab from that origin is closed
|
| I like this idea, but what browser config does this?
| gruez wrote:
| https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/
| ryukoposting wrote:
| I appreciate that there is at least one other person on earth who
| shares my skepticism of many popular MFA implementations. A lot
| of them add more inconvenience than security. "We sent a code to
| your email" is particularly heinous.
| anderspitman wrote:
| Other than the chance the email is delayed, and the generally
| subpar UX, what are your concerns with emailed codes? This is
| an honest question, as this is the primary login method I
| settled on for all my services after spending a good chunk of
| time thinking about this.
| tomjen3 wrote:
| For one thing, I now have to be logged in on my mail on the
| device I am using, and that means if the device is unsafe, I
| am exposing far more of a risk that way.
|
| It also forces me to look at my email inbox, which can be a
| pretty annoying thing if I am trying to relax and now see
| some email with bad news - requireing me to break the flow
| again.
|
| Most important however: it is simply wrong and not needed.
| The flow has been settled.
| anderspitman wrote:
| > For one thing, I now have to be logged in on my mail on
| the device I am using, and that means if the device is
| unsafe, I am exposing far more of a risk that way
|
| What's preventing you from getting the email code from
| another device?
| kunalgupta wrote:
| fingerprint works, no? (e.g. "Built In Authenticators) everything
| else kind of silly if so
| agwa wrote:
| > _API keys are used to secure the highest-stakes APIs that exist
| today -- all of AWS 's services, for example. Yet while API keys
| seem to be considered an entirely reasonable and industry
| standard design approach,_
|
| This is not actually true. API keys are highly disfavored because
| they are easily stolen, and these days if you try to create an
| access key in AWS, you'll be shown a screen called "Access key
| best practices & alternatives" which tries to get you to use
| something else (such as temporary credentials from the EC2
| metadata service). There's even federation between providers now,
| so for example if you need to access your AWS account from a
| GitHub Action, you don't need to use API keys
| (https://docs.github.com/en/actions/deployment/security-harde...)
| oh_my_goodness wrote:
| Ok. How about I make up a high entropy password and _you_ use it.
___________________________________________________________________
(page generated 2023-07-22 23:01 UTC)