It’s 2023, why are websites actively preventing pasting into fields like passwords and credit card number boxes? I use a password manager for security, it’s recommended by my employer to use one, and it even avoids human error like accidentally fat-fingering keys, and best of all with the credit card number I don’t have to memorize anything or know a single digit/character!

I have to use the Don’t Fuck With Paste addon just to be able to paste my secrets into certain monthly billing websites; why is my electric provider and one of my banks so asinine that pasting cannot be allowed? I can only imagine downsides and zero upsides to this toxic dark-pattern behavior.

There is even a mention about this in NIST SP 800-63B, a standard for identity management that some companies must follow in the USA, which mentions forcefully rotating passwords and denying “password paste-in” as antiquated/bad advice:

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets

Edit: I discovered that for Firefox users there’s a simpler way than exposing your secrets to someone’s third-party addon. Simply open about:config, search for dom.event.clipboardevents.enabled, and change it from true to false.

Edit 2: As some have pointed out, that config value interferes with regular functionality on some sites. Probably best to leave it alone unless you know what you’re doing.

    • manitcor@lemmy.intai.tech
      link
      fedilink
      English
      arrow-up
      6
      ·
      edit-2
      1 year ago

      this is not dissimilar to how high security setups work for organizations now, really what this is is a scaling up of the kind of things IT administrators are already doing when locking down production among other systems (its a very common login pattern for Linux based systems for thier SSH terminals).

      The big difference here is that your password changes from a password to a digital signature bound to time, hardware and the user. If the user so chooses they can always put a many levels on top of that that they want, be it passwords, additional keys, biometrics, what-have-you.

      Since your credentials never leave your device data breeches do not compromise your account or access to it (only the data the provider failed to protect). This also enables even higher levels of security through the whole credential chain, want to end-to-end-encrypt your data and encode it with your own cipher while storing it in the providers database? This is not only possible it will end up changing how we develop some applications. As a developer I just want to give you the utility, if I can ensure strong encryption that I NEVER have access to, its a whole boat of liability I don’t even have to worry about.

      In short we are taking the mechanics of auth and making it entirely cryptographic with keys without any worry about compromising a simple text input box. The possible combinations of certificate data and system parameters alone increases the difficulty of a breech through login significantly.

      It will not stop everything of course, and the usual risks around a bad release, a failed audit and an admin bypassing things knowing or unknowingly are all still problems.

      The other thing this enables, should it get that far, decentralized replacement of Google/MS/Amazon auth systems many of us MUST gate our sites with, youll be able to accept logins from multiple systems without ever having to write any new code. As the standard becomes adopted and supported firing up a site with all the usual traditional logins combined with the more-modern cert-style setup will no longer be a game of dealing with app setups and IAM, you can just load and go.

      Example of difference here: I could paste my public key to my prod systems here on lemmy and it would not change a thing about access to my systems, no one with the key or any of my signatures could do anything. With certificate based auth we know both sides of the transaction as well so MITM is not a thing in most scenarios.

      • can@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        Thank you for the detailed reply. I just had other things in mind. For important things, sure, but I kind of appreciate the ability to give some website a username, password, and maybe an email and that’s all the ask.

        I know IPs and browser fingerprinting kind of make this moot anyway.

        • manitcor@lemmy.intai.tech
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          you won’t even give them that in this kind of system. you will get a user hash that is based of your signature, the system your using’s key and some mux of time and entropy input. This hash will be how they track you in a database and as systems evolve could even be a way to communicate with the user directly (like email) without knowing or holding any PII/NPI

          Anything you assign to them would be data they have (maybe a common display name). Anything truly important that needs to be up there can be encrypted with different techniques that would allow the provider to work with your data without ever having to access or decrypt your data.

          so the idea of them “needing to have something” to function is true, but fundamentally, they don’t need as much to operate in this system and its possible to have standards that enforce security on your more sensitive details that are sent. Imagine the security of your data, on thier system, still being ruled by your security. Even if hackers get in and copy the entire database its effectively useless.