GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 10:46:24 JST Glyph Glyph

    This is a great writeup of the continuing failure of passkeys to meet their potential. It demonstrates the gordian knot:

    1. the ecosystem is confusing due to the plethora of different interacting layers
    2. therefore, to simplify, every vendor attempts to own as many layers as they can, obscuring other vendors' tools
    3. therefore, users are confused into thinking that passkeys are platform-specific, because their platform vendor is obscuring alternatives

    https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/

    In conversation about 5 months ago from mastodon.social permalink
    • Rich Felker repeated this.
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:17 JST Glyph Glyph
      in reply to

      This is a particularly painful and comprehensive example of an industry-wide trend, which is that vendors are expected to deliver things as fully-formed, self-explanatory products. Users, already justifiably wary of the upgrade treadmill, reflexively flinch away from anything that looks like a big learning investment, which means "user education" is treated as a sort of taboo, something that *cannot* be made a prerequisite to using a product, because if you're explaining, you've already lost.

      In conversation about 5 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:54 JST mcc mcc
      in reply to

      @glyph I'm going to add something, it's not as big as the other problems you raised but I think it's a problem: Someone, somewhere, set it up so the non-vendor-locked version of passkeys so it *requires*, per the spec, for you to use Bluetooth, which simply means I will never use it. This is probably childish. But I am probably not the only person who hears "bluetooth" and immediately tunes out.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:55 JST Glyph Glyph
      in reply to

      Almost every communication technology is like this. Email is bad so we *still* keep getting new email clients that try to "solve" email (or chat apps; remember when slack was going to "solve" email?). Don't worry, don't change your habits, you don't need to learn anything, just click this button. We made a "promotions" tab, and an "important" tab for you, so now you won't be overloaded. Just consume product, don't learn to be a better communicator. Here are some suggested AI replies.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:55 JST Glyph Glyph
      in reply to

      People need to develop sophisticated strategies and think deeply about their values and goals when using social media, but the only response that social media companies have to this is to introduce features or to constantly tweak their recommendation algorithms. Disinformation? Oh, that's okay, we'll block the word "suicide" so now everyone starts saying "unalive yourself in minecraft", great, teen mental health is solved. No need to have a difficult conversation about norms and pedagogy.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:55 JST Glyph Glyph
      in reply to

      I can't blame companies; users really do reflexively avoid learning, and have been conditioned to see their primary feedback mechanism as switching apps. If your app requires learning, you'll see massive churn and be harshly punished for that. I definitely can't blame users, who avoid learning because developing deep expertise with modern apps is rewarded by having your brains scrambled with constant A/B tests of everything being reshuffled to suit the users who *don't* put in effort.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:55 JST Glyph Glyph
      in reply to

      In a way, you can see the passkeys community pushing *against* this trend, trying to acknowledge this need, developing resources like https://webauthn.io to allow users and developers to cultivate a structured understanding of the technology as a whole, decoupled from vendor-specific solutions. But the ingrained product development habits from every vendor undermine this.

      In conversation about 5 months ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: webauthn.io
        A demonstration of the WebAuthn specification
        from @duo_labs
        Demonstration of the WebAuthn specification.
      Rich Felker repeated this.
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:58:56 JST Glyph Glyph
      in reply to

      The failure of passkeys to date is a particularly dramatic example of this because it's extremely high-stakes, visible, and black-or-white (you're either switching your auth to passkeys or you aren't, whereas other apps you may use in a casual or incorrect capacity). But the same problem exists in other domains, and it's almost as bad.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:59:18 JST Glyph Glyph
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @whitequark @mcc I'm not really clear on what "non-vendor-locked" means here, but it sounds like people aren't paying attention to an extremely stupid corner of the spec, so: great

      In conversation about 5 months ago permalink
      Rich Felker repeated this.
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:59:18 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc

      @glyph @mcc i am using a password manager with a browser extension that lets me do passkey logins in most places i've tried to do them

      keepassx stores them in the password database, like everything else it stores

      it's a normal file

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:59:19 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc

      @mcc @glyph i am using non-vendor-locked passkeys with zero bluetooth

      (keepassx supports it)

      In conversation about 5 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:59:19 JST mcc mcc
      in reply to
      • ✧✦Catherine✦✧

      @whitequark @glyph 🤔 are the passkeys stored on the same physical device that they are utilized on

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 31-Dec-2024 17:59:19 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc

      @mcc @glyph yes

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 18:00:27 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @whitequark @glyph @mcc AFAICT passkeys are a half-baked solution to a non-problem that was already solved by "use a password manager and let it generate strong passwords".

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 18:04:06 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @whitequark @glyph @mcc That's assuming you want to store the keys on a separate device, which is a really bad idea for most normal users.

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 31-Dec-2024 18:04:07 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc
      • Rich Felker

      @dalias @glyph @mcc PKI-based authentication is strictly better than what you're suggesting since you can no longer steal a credential (other than from the password manager), no matter what happens with the browser or the website

      In conversation about 5 months ago permalink
      Rich Felker repeated this.
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 18:12:45 JST Glyph Glyph
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @whitequark @dalias @mcc yes. the key detail here is that the PKI involved *includes the domain of the site* so phishing goes from "mild difficulty if the user has a PTSD level of hypervigilance, easy if they're not really paying attention" to "physically impossible without local code execution or device theft". the differences are huge. the difference is big enough that the FTC has occasionally given it the force of law: https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2023/02/security-principles-addressing-underlying-causes-risk-complex-systems#_ftnref6

      In conversation about 5 months ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: www.ftc.gov
        Security Principles: Addressing underlying causes of risk in complex systems
        from @FTC
        On December 14th, 2022, in collaboration with technologists on team CTO and attorneys in BCP, I gave a presentation at the Federal Trade Commission’s
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 18:12:45 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @glyph @whitequark @mcc Any proper password manager also matches the domain of the site and is not vulnerable to phishing.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Tuesday, 31-Dec-2024 18:14:00 JST Glyph Glyph
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @dalias @whitequark @mcc that is one possible benefit, but a minor one. the absolute vast majority of password theft is via normal user interactions via copy/paste or data breach dataset downloads, not via targeted implants and RCE of victim endpoints.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 18:14:00 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @glyph @whitequark @mcc If there's no RCE on the endpoint and no manual c&p bs (proper automated password manager), I don't see any advantage.

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 31-Dec-2024 18:26:40 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc
      • Rich Felker

      @dalias @glyph @mcc let's say you register on amazon.com, you save an entry, it's fine
      now, because you are in the UK, you get amazon.co.uk. it uses the same login, so you pull up your password manager, and either copy the password, or manually add it to the allowlist
      now, you get a phishing email with a link on amazom.co.uk. amazon has trained you to do this and you don't quite remember everything you've done, so you just do it again

      2/2

      In conversation about 5 months ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: g-ec2.images-amazon.com
        Amazon.com. Spend less. Smile more.
        Free shipping on millions of items. Get the best of Shopping and Entertainment with Prime. Enjoy low prices and great deals on the largest selection of everyday essentials and other products, including fashion, home, beauty, electronics, Alexa Devices, sporting goods, toys, automotive, pets, baby, books, video games, musical instruments, office supplies, and more.
      2. No result found on File_thumbnail lookup.
        Amazon.co.uk: Low Prices in Electronics, Books, Sports Equipment & more
        Sign up to Amazon Prime for unlimited free delivery. Low prices at Amazon on digital cameras, MP3, sports, books, music, DVDs, video games, home & garden and much more.
      3. No result found on File_thumbnail lookup.
        Amazon.co.uk: Low Prices in Electronics, Books, Sports Equipment & more
        Sign up to Amazon Prime for unlimited free delivery. Low prices at Amazon on digital cameras, MP3, sports, books, music, DVDs, video games, home & garden and much more.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 18:26:40 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @whitequark @glyph @mcc How does this workflow work with passkeys where the domain won't match? I would assume some kind of redirect to SSO-like thing on the canonical domain, which is how it should be done with plain passwords too (rather than training users to get phished, as you noted they're doing).

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 31-Dec-2024 18:26:41 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc
      • Rich Felker

      @dalias @glyph @mcc please imagine a real person without PTSD hypervigilance using a password manager

      1/2

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 20:36:00 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • lj·rk
      • ✧✦Catherine✦✧

      @ljrk @whitequark @glyph @mcc How is a person who doesn't know how to manage backups, and who doesn't have reliable possession of devices, supposed to use passkeys? This problem needs to be solved before they're anywhere near universally usable. Passwords they can memorize or write down on paper.

      In conversation about 5 months ago permalink
    • Embed this notice
      lj·rk (ljrk@todon.eu)'s status on Tuesday, 31-Dec-2024 20:36:01 JST lj·rk lj·rk
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @dalias @whitequark @glyph @mcc What, no, @whitequark didnt say anything about a separate device and the point still stands stands. It’s just pub/private crypto vs shared secrets. It’s one reason why we use SSH keys instead of passwords despite passwords being possible to generate uniquely and strongly.

      For sure, this problem has been “solved” in the sense that you (and me) just use a password manager, tweak its generator when websites want some different “secure” password requirement and know how to deal with the PITA if the passwords are shared across domains etc. Possibly even monitor HIBP and rotate the password in that case.

      But all this is something that requires domain knowledge and we should admit that. We failed to make computers useable by end users. Which would be fine if we wouldn’t require them to that.

      If Passkeys were implemented correctly the above problems wouldn’t appear, Phishing would almost completely be gone and it would even be easier for users. And “losing credentials” neither.

      I’m honestly surprised about this pushback by you. We’re effectively unrestricting FIDO2 which has been our go-to advice for ages and make the keys copyable like SSH keys are … and suddenly it’s all evil

      In conversation about 5 months ago permalink
    • Embed this notice
      Harshad Sharma (hiway@mastodon.social)'s status on Tuesday, 31-Dec-2024 20:38:18 JST Harshad Sharma Harshad Sharma
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @whitequark @dalias @glyph @mcc +1

      // I was wary of passkeys because of the hype by Big companies (never a good sign, as we can see now that it's been a while) - however I am satisfied with the solution via keepassx + firefox + syncthing. Works on all my machines on the sites where I've set it up.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 21:14:06 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • lj·rk
      • ✧✦Catherine✦✧

      @ljrk @whitequark @glyph @mcc "Through transparent E2E and synchronization b/w devices. This mythological technology that they are... you know... widely using already."

      They absolutely are not. There is no such thing by default, only if all your devices are from a single platform authority (Apple, Google, or Microsoft) and you trust them. Most people do not fit it that category.

      Even on Apple's walled garden ecosystem it's hard af to get this magical transfer to new device to work.

      In conversation about 5 months ago permalink
    • Embed this notice
      lj·rk (ljrk@todon.eu)'s status on Tuesday, 31-Dec-2024 21:14:07 JST lj·rk lj·rk
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @dalias @whitequark @glyph @mcc Through transparent E2E and synchronization b/w devices. This mythological technology that they are... you know... widely using already.

      Also: You yourself brought up password managers and generated unique passwords. Which have literally the same problem: If you lose access to it, you lose access to the sites you've logged in to. And the high # of log ins make it unrealistic to memorize or write the passwords down. If you really think that's what they're do then you're widely out of touch with the general user's reality.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 21:14:59 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • lj·rk
      • ✧✦Catherine✦✧

      @ljrk @whitequark @glyph @mcc Only critical passwords like your email actually have to be written down. Everything else you just do a reset via email.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 21:33:11 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • lj·rk
      • ✧✦Catherine✦✧

      @ljrk @whitequark @glyph @mcc I have never encountered normies using that.

      In conversation about 5 months ago permalink
    • Embed this notice
      lj·rk (ljrk@todon.eu)'s status on Tuesday, 31-Dec-2024 21:33:13 JST lj·rk lj·rk
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @dalias @whitequark @glyph @mcc

      > They absolutely are not. There is no such thing by default, only if all your devices are from a single platform authority (Apple, Google, or Microsoft) and you trust them. Most people do not fit it that category.

      Okay, you *are* widely out of touch. Chrome alone has about 68% market share and has a built-in E2E password manager that works on Linux/macOS/Windows/Android + syncs with the Android keystore for use outside of the browser. I wouldn't call that "single platform authority" but either way, *a lot* of users use this. We may not like it but that's how it *is*.

      > Even on Apple's walled garden ecosystem it's hard af to get this magical transfer to new device to work.

      *if* you are in Apple's walled garden it's just in iCloud and transparently on all your devices.

      > Only critical passwords like your email actually have to be written down. Everything else you just do a reset via email.

      That's one solution. Which, you know, will work with passkeys too, so you've just invalidated your whole fucking point.

      (Besides: I'd love to rip out email from this too in the future because it undermines the whole security but that's outside of the scope of this discussion.)

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 21:35:43 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • lj·rk
      • ✧✦Catherine✦✧

      @ljrk @whitequark @glyph @mcc Re: iCloud, it's not synced to your Windows PC. If your only two devices are a Windows PC and an iPhone (very typical) there is no easy way to do what you're claiming is easy.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 31-Dec-2024 21:46:22 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • lj·rk
      • ✧✦Catherine✦✧

      @ljrk @whitequark @glyph @mcc You can probably configure it to do that. It's not the automatic default experience out of the box, and shouldn't be (it involves these hostile authorities poking at each other's stuff on your devices), and it's not what most people are living with. This doesn't matter because they're using passwords. If they were suddenly forced to use passkeys, they'd be confused and locked out all over the place.

      In conversation about 5 months ago permalink
    • Embed this notice
      lj·rk (ljrk@todon.eu)'s status on Tuesday, 31-Dec-2024 21:46:24 JST lj·rk lj·rk
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @dalias @whitequark @glyph @mcc You have not encountered normies using Google Chrome? And you may argue that it's a single platform authority, but the statement is then widely misleading as you can use very different systems beneath. But idc, the reality is that people use it, you like it or not.

      And yes, iCloud is not synced to Windows. But you said, I quote:

      > Even on Apple's walled garden ecosystem

      and to my knowledge Windows is not part of the Apple walled garden. Regardless though, Apple Passwords syncs to Chrome and Edge (~80% market share, much higher if you restrict to Windows only for your example) just fine...

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 01-Jan-2025 11:08:13 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • Falcon Darkstar
      • ✧✦Catherine✦✧

      @falcon @glyph @whitequark @mcc The topic was not whether the pasting side should disallow pasting password (absolutely not, and browsers should fix the design bug that lets them by making paste indistinguishable by js from typing), but whether copy fron pw manager should be used/allowed vs auto entry (generally no; need for c&p should be a huge red flag).

      In conversation about 5 months ago permalink
    • Embed this notice
      Falcon Darkstar (falcon@mastodon.falconk.rocks)'s status on Wednesday, 01-Jan-2025 11:08:14 JST Falcon Darkstar Falcon Darkstar
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @glyph @dalias @whitequark @mcc it is actually the NIST recommendation to *allow* password pasting, because the alternative, typing it, is completely worse. Passkeys are nice because it changes that mess into an actual defined protocol.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:08:15 JST Glyph Glyph
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @dalias @whitequark @mcc please, please trust me when I tell you that you cannot tell people not to copy and paste a password into a web page when their job is copying and pasting passwords into web pages all day long. people _routinely_ circumvent domain restrictions on password pasting. smart people. security-aware people. it is easy for social engineers to create synthetically exigent situations where this seems like a reasonable and obvious thing to do.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 01-Jan-2025 11:12:38 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @glyph @mcc @whitequark It's my view that the "social problem of password reuse and account compromise" is a problem mostly for sites, not actual people, users, and trying to force users to change behavior & put themselves at risk of credential loss to solve it is hostile cost externalization.

      Most compromised passwords are for garbage accounts people never wanted to have. They should have been offered ability to use service without account or with Craigslist style login.

      In conversation about 5 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:12:39 JST mcc mcc
      in reply to
      • Rich Felker
      • ✧✦Catherine✦✧

      @whitequark @dalias @glyph Because we all want different things, some of us don't get them. Catherine seems satisfied with her passkey implementation, but glyph is not satisfied because for convenience it's been watered down to being not quite anti-phishy enough, and I— who wanted SRP but do not care at all about "phishing"— don't get SRP, because the "anti-phishing" rules erect barriers to me using my passkeys in the way I want (without transferring the keys to certain untrusted devices). (4/4)

      In conversation about 5 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:12:39 JST mcc mcc
      in reply to
      • Rich Felker
      • ✧✦Catherine✦✧

      @whitequark @dalias @glyph Passkeys were trying to be too many things to too many people and I think this made them worse.

      In conversation about 5 months ago permalink
    • Embed this notice
      Glyph (glyph@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:12:39 JST Glyph Glyph
      in reply to
      • mcc
      • Rich Felker
      • ✧✦Catherine✦✧

      @mcc @whitequark @dalias I think there is some validity to what you're saying—in particular, I think that passkey implementations could do a better job respecting individual autonomy and allowing individuals to provide input to their threat model, which the big vendors cannot have and is not universal.

      But to the extent that "passkeys" are trying to do a thing, it's to solve a big *social* problem of password reuse and account compromise, which other solutions have demonstrably not addressed

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:12:40 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc
      • Rich Felker

      @dalias @glyph @mcc i said nothing about a separate device

      In conversation about 5 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:12:40 JST mcc mcc
      in reply to
      • Rich Felker
      • ✧✦Catherine✦✧

      @whitequark @dalias @glyph I said something about a separate device (in a different part of the thread)

      Continuing from here:

      https://mastodon.social/@mcc/113748384835298072

      …in addition to the website not being trustable with your password, it's also possible the machine on which the web browser is running cannot be trusted with your password. This is an important case to me personally, not on *all* machines, but on some machines separately.

      Here I note something important and problematic:

      (Post 2 of 4)

      In conversation about 5 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Wednesday, 01-Jan-2025 11:12:40 JST mcc mcc
      in reply to
      • Rich Felker
      • ✧✦Catherine✦✧

      @whitequark @dalias @glyph The thing I want out of passkeys is completely different from what Catherine wants out of passkeys, which is (I think) different from what Glyph wants! I want SRP. I want authentication without the shared secret (password) having to travel from its trusted home (whereever that is) to the authenticating party, thus hitting peril from lazy/malicious Twitter engineers, malwared Microsoft Windows, etc. Glyph wants anti-fishing. Catherine wants (I think) convenience. (3/4)

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 01-Jan-2025 19:00:22 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc
      • Rich Felker

      @dalias @glyph @mcc don't a lot of people reuse passwords between "trash site nobody cares about" and "gmail with keys to their kingdon"? like this is how a bunch of high profile people got popped, afaik

      i agree re: accounts being pointless, but also like... how would you enforce that? EU decree? no idea what else

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 01-Jan-2025 19:00:22 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @whitequark @glyph @mcc One obvious mandate: to put a clear warning on the signup page: DO NOT GIVE US YOUR EMAIL PASSWORD.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 01-Jan-2025 19:07:14 JST Rich Felker Rich Felker
      in reply to
      • mcc
      • ✧✦Catherine✦✧

      @whitequark @glyph @mcc Yeah but there's only so much you can do. One other feature that would help on the browser/pw-manager integration side: tracking "important" site passwords and interrupting/warning you if you try to use the same password on another site.

      In conversation about 5 months ago permalink
    • Embed this notice
      ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 01-Jan-2025 19:07:15 JST ✧✦Catherine✦✧ ✧✦Catherine✦✧
      in reply to
      • mcc
      • Rich Felker

      @dalias @glyph @mcc the problem is that people ignore these things

      In conversation about 5 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.