19 ms·

Why even let users set their own passwords?

• kunalgupta 3y ago
  fingerprint works, no? (e.g. “Built In Authenticators) everything else kind of silly if so
• paddw 3y ago
  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 3y ago
    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 3y ago
    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 3y ago
  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 3y ago
    That’s an interesting POV. Thanks!
  • simias 3y ago
    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 3y ago
      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 3y ago
        Yeah that's a good point, I definitely that automatically generated passwords should be limited to alnum, using symbols is asking for trouble.
        • kwhitefoot 3y ago
          In what character set?
          • anticensor 3y ago
            ASCII?
            • kwhitefoot 3y ago
              What about people who use non-ASCII sets?
  • eviks 3y ago
    You're not supposed to type your password!
• danparsonson 3y ago
  > 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 3y ago
  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.
  • cm2012 3y ago
    It's not just old people. I'd say 80% of people would not use a website with that system.
  • xcxcx 3y ago
    [flagged]
    • FredPret 3y ago
      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
    • samwillis 3y ago
      Gosh, you're fun.
    • tylerrobinson 3y ago
      Using economics terminology doesn’t make this insensitive opinion any more valid. Technology is for people, not the other way around.
• deleted 3y ago
  [deleted]
• Attummm 3y ago
  How would you share the password with the users without revealing it to others? How would a users use different devices?
• kelseyfrog 3y ago
  Ikea effect. People are more likely to complete the new user funnel if they felt they had a role in building it.
  • anderspitman 3y ago
    This made me chuckle, and it honestly might be true.
• goalieca 3y ago
  With passkeys they won’t. Let’s move on already!
• laputan_machine 3y ago
  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 3y ago
    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 3y ago
      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.
      • orev 3y ago
        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.
• raesene9 3y ago
  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).
• belinder 3y ago
  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 3y ago
    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.
• iambateman 3y ago
  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.
  • eviks 3y ago
    It doesn't work great, with a password I have a single shortcut to autofill from the password manager With a stupid email login I have to do many more steps (and email isn't 100% reliably immediate)
• 38 3y ago
  > 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.
  • fieryskiff11 3y ago
    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 3y ago
      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 3y ago
    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.
• simias 3y ago
  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.
• madeofpalk 3y ago
  This is basically exactly what WebAuthN/Passkeys is, right?
  • krupan 3y ago
    That's like saying: IPv6 is basically IPv4 with bigger addresses, right?
    • madeofpalk 3y ago
      It’s like saying “we shouldn’t have to worry about ip address starvation”, and having IPv6 as exactly the solution
      • krupan 3y ago
        Righ, so 20 years from now we'll all still be using passwords while a few people play around with webauthn
• unboxingelf 3y ago
  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 https://github.com/nostr-protocol/nips/blob/master/19.md
• lolinder 3y ago
  > 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.
  • londons_explore 3y ago
    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.
    • eternityforest 3y ago
      Cookies already last months or years, I don't think the tech limits duration so much as the sites explicitly set a time, or clear the token on the backend. What I'd really like is to just be able to use the native filesystem. But Firefox doesn't like that, and people apparently use that, so it's not a real standard. At the very least, they should make the origin private filesystem user-visible with a flag. Don't allow everything, just ~/WebData/default/DOMAIN_NAME
• khromov 3y ago
  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-application-architecture-with-sveltekit/ https://khromov.se/building-a-privacy-friendly-self-hosted-a...
• sixstringtheory 3y ago
  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 3y ago
    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 3y ago
      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.
• deleted 3y ago
  [deleted]
• _8j50 3y ago
  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.
• haunter 3y ago
  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
  • crote 3y ago
    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 3y ago
      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 3y ago
    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.
  • HoppyHaus 3y ago
    Those are called "magic links"
  • drpixie 3y ago
    I know plenty of people who use that approach for all but their most used accounts ... just click on the "reset password" link, use it, and forget the new password! It works but it's incredibly heavyweight. For every login you use an entire email infrastructure, doing all the email "security" processes. That a great deal of work.
• rvz 3y ago
  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.
• upofadown 3y ago
  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.
  • __ryan__ 3y ago
    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 3y ago
      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__ 3y ago
        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.
  • codetrotter 3y ago
    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.
    • 3y ago
• amarshall 3y ago
  > 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 3y ago
    https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/ https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/
• agwa 3y ago
  > 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-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services https://docs.github.com/en/actions/deployment/security-harde...)
• oh_my_goodness 3y ago
  Ok. How about I make up a high entropy password and you use it.
• crote 3y ago
  > 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.
  • justsomeadvice0 3y ago
    > 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.
  • deleted 3y ago
    [deleted]
  • ec109685 3y ago
• Pxtl 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
    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 3y ago
      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.
• jdthedisciple 3y ago
  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 https://news.ycombinator.com/item?id=36717356
  • H8crilA 3y ago
    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.
    • jdthedisciple 3y ago
      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 3y ago
        >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.
• NelsonMinar 3y ago
  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.
• seabass-labrax 3y ago
  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 3y ago
    > 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 3y ago
      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.
• two_handfuls 3y ago
  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 3y ago
    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 3y ago
      I was talking about first-party cookies. Third-party cookies don’t have this ambiguity, they’re unequivocally bad.
      • lolinder 3y ago
        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.
• varelse 3y ago
  [dead]
• justsomeadvice0 3y ago
  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 3y ago
    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.
• ryukoposting 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        > 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?
        • tomjen3 3y ago
          Thats assuming I have it on me. I might not, or I might need to dig it out of a bag.
    • eviks 3y ago
      The first two reasons are enough to disqualify it
• CyberRage 3y ago
  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 3y ago
    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.
    • kortex 3y ago
      > 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.
    • CyberRage 3y ago
      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
• causality0 3y ago
  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.
• AndrewKemendo 3y ago
  >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
• gerbilly 3y ago
  Cos we want to be able to blame the users when there is a data breach. :-)
• KnobbleMcKnees 3y ago
  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 3y ago
    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.
    • KnobbleMcKnees 3y ago
      Yes, 2/3FA with a hardware key and push for login and access to anything security critical, and 2FA via push for everything else.
  • amelius 3y ago
    > comprised of four space-separated words correct horse battery staple? https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength https://www.explainxkcd.com/wiki/index.php/936:_Password_Str...
  • dredmorbius 3y ago
    NB, the EFF's "diceware" passphrase generator method recommends six words for effective security: <https://www.eff.org/dice https://www.eff.org/dice> Note that if your attacker knows the dictionary used, the effective strength of a passphrase isn't based on its string length but on the number of individual words within the phrase. Six words gives an effective key strength of 2^77 bits.
• deleted 3y ago
  [deleted]
• AlbertCory 3y ago
  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.
• no_wizard 3y ago
  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
• gumby 3y ago
  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.
• hartator 3y ago
  > 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 3y ago
    That's pretty much the point the blog post is making.
• cushpush 3y ago
  Password replacements are like septic systems, everyone needs one and nobody wants to do the work.
• tenebrisalietum 3y ago
  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.
  • eviks 3y ago
    You don't know, you just generate it
• exabrial 3y ago
  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.
• summerisle 3y ago
  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 3y ago
  Fwiw, those long lived API keys in AWS used as an Argument are since years not considered a best practice. Short lived creds for the win!
• j45 3y ago
  Learning safe passwording is now a life skill. As or more important as house keys
• s-xyz 3y ago
  I am not an expert on the matter, but it feels like the same concept as Passkeys.
• wizofaus 3y ago
  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.
• teddyh 3y ago
  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.
  • BenjiWiebe 3y ago
    Just so your idea of random and secure isn't flawed... Some websites think they enforce secure passwords, but don't seem to understand that a random password will occasionally have duplicate characters, or might include symbols other than @!#$, or might be longer then 10 characters.
• m463 3y ago
  It seems folks are going the other way. Instead of eliminating passwords, they are added to something else to get 2FA.
• nullc 3y ago
  hm? We let users set their own passwords because users are unable to remember secure passwords, which would create a lot of work for people running the service (and the user as well), even vulnerabilities because we'd be habituated to recovering lost passwords. When the user can set their password they will set an insecure one that they can remember, eliminating most of the password reset work. Then when the user is compromised it's their fault. This compromise works because most users aren't particularly vulnerable-- no one is trying, or no one cares if they are compromised. Why don't we just rely on the recovery security? well Mozilla's persona thing pretty much did.
• linuxrebe1 3y ago
  I'll ask, in the corporate world. Why even allow them to know their password. To login to their device a Yubi Key or Door key could be used (or similar) then once logged into their laptop they have an app the works like 1password or lastpass that inserts their passwords, updates their passowrds etc. for everything the company uses. (If they have a reddit account that is non corporate they could use their own pw manager.) This would also solve the "shared password" issue where a company that has a corporate Twitter account, they control access to the credentials and the credentials. Also gives you a paper trail in that you now know who used the credentials at the time of a post.
  • NBJack 3y ago
    What happens when that key is stolen or lost? Would it be acceptable risk in your model to allow anyone to use it? I'm not saying you're wrong, but it would be a definitive trade off.
• shalmanese 3y ago
  Usernames and passwords are effectively obsolete in China. It's a combo of: * All accounts need to be tied to an identity, generally in the form of a Mainland Chinese phone number which is linked in the backend to a Government ID/Foreign Passport * Mobile first development where mobile is assumed to be the primary or only way to interact with most services. * Overwhelming dominance of two 3rd party identity providers (WeChat and Alipay) * WeChat mini-apps taking over most of the small use cases where authentication is baked in. The usual flow is that you sign up with a phone number as your username and authenticate with SMS 2FA. Because it's a mobile app, it doesn't have to deal with web bullshit and actually remembers you across sessions spanning months. To reauthenticate on a different device, you just enter your phone number and use the same SMS 2FA to login. The web flow for a lot of sites is that they require you to open the logged in mobile app and scan a QR code to login on the web. A few legacy sites like Taobao still support password login but they're by far not the majority.
• bhawks 3y ago
  The author has enough knowledge to be dangerous and shouldn't be allowed anywhere near an authentication system. The first diatribe against 'nondeterminstic' logins demonstrates a naivety to both account takeover and botting mitigations. Passwords have to be assumed to be low entropy long lived credentials which are horrible from nearly every standpoint. API keys at least have a high entropy but are long lived and difficult to secure. (How many times do we need to see apikeys accidently leaked in a pull request?). They also do nothing from a phishing perspective. OTP is a high entropy and the authenticated credential exchanged has a very short lifetime. The exchanged credential may also be much shorter. It is still susceptible to phishing mitm attacks. Thankfully it's 2023 and webauthn is here for the browser. We can keep long lived secrets in a secured environment, be resistant to phishing and if the risk model includes physical loss of device utilize pins / passwords even if they are low entropy.
• g42gregory 3y ago
  I love the title. Taking it further: Why provide any functionality to users at all? What do they know? Just charge them the money.
• MagicMoonlight 3y ago
  Lmao this guy deletes the cookies to log himself out every time he closes a tab and then has to do 2FA every time he uses any website and he thinks it is the system that is wrong.
• Alifatisk 3y ago
  I am thinking loudly now. Nowadays, websites and apps force users to follow a certain pattern when setting their password. Since users have to comply in order to successfully proceede with setting their password, does it still count? (Count as in letting users set their own password)
• btbuildem 3y ago
  I had a very different idea of what this article was going to be about before I read it. Since the article is kind of an irrelevant rant, let me share what I thought the title was encapsulating: Corp policies asking users to change their passwords every 60 days or whatever, combined with the ever-more-arcane password content requirements -- yes, why the HELL are you asking me to change my password? I'll just go to one of the online passgens, generate a string, and immediately save it in a text file in my local home directory, because there's no way I will remember it. Might as well generate passwords for your users already. Don't email me asking to come up with my own, send me a link to a form where I can copy the new password from.