- cross-posted to:
- hackernews@derp.foo
- cross-posted to:
- hackernews@derp.foo
DNA companies should receive the death penalty for getting hacked | TechCrunch::Personal data is the new gold. The recent 23andMe data breach is a stark reminder of a chilling reality – our most intimate, personal information might
Oh yeah? So on Android… How do you get your password manager to work for your passkey storage? Because all I see on android is NFC, USB, and “This device” (which is literally google storage, not your own app). So how do you login to any apps that you’re using passkeys on your phone?
LMFAO, you’ve addressed basically nothing and assume that your answers are sufficient you can fuck right off.
Edit: This is effectively SSL/TLS… Right? So there’s never been a successful attack on that right? Boy do I have a bridge to sell you.
Currently I only use passkeys on desktop while I patiently wait for my password/passkey manager of choice to finish implementing passkey support on Android, just as I’m waiting for most services themselves to implement passkey support in general. It’s a relatively new and emerging technology, adoption always takes time.
When you don’t put any thought into what you’re using and just stick with the defaults you’re given; you’re obviously not going to have an optimal experience. Hence: Do better.
No, this is not basically TLS/SSL. TLS/SSL convinces a client to use a key they’ve just been given, via a public chain of trust that can be manipulated in many ways. This is more akin to the public key authentication of an SSH connection; where the keys are known and trusted long before the connection where they are used is established. This is then also wrapped in TLS/SSL as an additional layer. But TBH as long as you don’t pass persistent login tokens back/fourth, it could be done over plain http. (it wouldn’t secure the data then ofc, but would still securely prove your identity across that connection)
And yet here we are… you can’t use it the way you want even if you wanted to. And have no guarantee that that functionality will ever be supported on your platform. Yet you’re saying “do better” when better literally cannot be done.
You do not understand TLS/SSL then. Public chain of trust is not a requirement. You can import and trust whatever cert you want. And there’s been a history of attacks SPECIFICALLY doing that.
Which password auth is at this point on the internet as well… yet in previous posts you made it out like passwords are sent over the clear and are sniffable by the whole world.
A new tech has not yet been adopted everywhere yet so we should abandon it entirely? That’s quite the take.
Patience my friend. Good things come in time.
Yes, TLS/SSL is flawed. Again: no, this is not an implementation of TLS/SSL.
No, I’ve not implied passwords are sent over open channels. I’ve said their transmission -at all- is a bad thing (which they have to be to be used), regardless of being wrapped in TLS/SSL.
Copy/paste from another conversation:
A random example: If I login to twitter with a password using a work computer, that password is more than likely now sitting in a log file on the corporate firewall that performs https inspection. That could be used to gain access to my account later.
Replace that password with a passkey, and now there’s no ability to harvest and use login info from those logs. All they saw was the passkey challenge and response sent back/fourth with no ability to replicate it later.
(How I got the passkey onto a work computer is separate discussion, point is the example of collecting your password via a malicious network connection. This can happen in more than just a work environment)
No, it offers nothing that cannot be done with current implementations of passwords/password managers. That’s the take. You’re just obtuse and unable to answer how your precious passkeys is actually better in any form.
It’s literally what it is… It’s what industry experts directly call it. Public/Private keys… That’s all this is… that’s literally how TLS/SSL works.
They don’t… because well implemented passwords should only send hashes… Which we’ve already established that passkey implementation is also problematic. You can’t compare the worst implementation of passwords to best implementation of passkeys. That is disingenuous. Nothing about passkeys forces a website to implement things “properly”, just like they don’t have to for passwords.
Doesn’t stop MitM, doesn’t stop corporate firewall from capturing the session cookie and utilizing that to replay access to your account. Assumes that the challenge and response are implemented so that it’s not guessable nor repeated… Keep in mind, we can hash/salt passwords in a multitude of ways, which can be used to vary the “response” of a password as well.
But it’s not. If I want to login on a work computer with a password. I can just type the damn thing in. Passkeys are simply LESS mobile… and carry more risk as you’re now authorizing a specific machine to have permissions indefinitely rather than having sessions that defacto expire and that’s it.
But let’s actually reign this in a bit… What are the actual beneficial claims here?
Do you agree that something like https://b-compservices.com/switching-from-passwords-to-passkeys/ encompasses all of it?
Can accomplish the same thing with passwords that they claim passkey can do. Whether someone implements it that way is a different problem. But it’s possible.
Also makes it significantly harder for companies to support users. I cannot set a passkey to a known value to let someone into their account after they lock themselves out (likely forgetting their own password).
I’ve had this with password managers for a decade… if not longer at this point. And it works on all my devices, so it’s even more smooth!
See above…
Anyone who says this in the context of computer security is lying from the get-go.
Same as “Smooth user experience”.
Their logic here is moronic. “This includes the time IT spends dealing with the constantly changing legal requirements for password storage and password resets.” Except now people will just be locked out and fucked completely. Unless they happen to use a flawed passkey implementation that allows them to recover their shit no?
Public Key Auth =/= TLS/SSL =/= Passkeys.
TLS/SSL is one implementation of public key authentication.
Passkeys is a different implementation of public key authentication.
That fact that there are flaws in the TLS/SSL implementation of public key authentication does not equate to those flaws being present in the Passkey implementation of public key authentication.
Just because a tool was used poorly once, doesn’t mean it’s always used poorly.
Passwords MUST be transmitted to the service in a form that the server accepts as valid, every time authentication is requested. This can be captured and re-sent in exactly the same form it was originally sent to the server. Be that plaintext, or a hash. Hashing a password is almost always done on the server side before storage, or before comparing to the stored hash. If it was done by the client, an attacker would never need to get the plaintext password, they could just resend the hash. A passwords security in transit is entirely dependent on the security of the SSL/TLS connection, which we’ve already discussed is flawed.
A passkey is never transmitted and thus cannot be stolen from that transmission. They are not dependent on the security of a known to be flawed network protocol.
Yes, there are other attack vectors which are present with both forms of authentication. Not really relevant to choosing one or the other being they are present regardless of password vs passkey.
The only problem we’ve established with passkeys is managing their storage and distribution between your devices. That’s a problem that’s entirely up to you as a user and which managers you choose to use. I like having detailed control over my data, so I used a self-hosted password/passkey manager. Others don’t care to go into that kind of detail and just stick with google/apple. To each their own.
I’m actually doing the opposite: Compairing the best password implementations with the worst passkey implementations. (regarding how the service implements auth, not how the user manages their auth info. Ie; what the user has no control over)
Even with the user and the service they are using doing all the right things to secure their password auth as much as possible: that password can still be stolen in a usable form either from the service itself or from the connection between the service and the user.
Where as a service could fuck up astronomically; http only, with public access to their user+passkey table. As long as the users own systems have not been compromised, those passkeys cannot be stolen in any useable way as the service doesn’t have them and are never sent them in any form. All you’ll get is a public key which is about as useful as a random number.
Passkeys move all the risk+responsibility of keeping them secure away from the service and puts it entirely in the hands of the user and the decisions they make. You no longer have to hope or even care that the service you’re connecting to is actually utilizing the best practices.
And yes, Passkeys are more inconvenient than a password. Using private key auth has always been more inconvenient. Doesn’t stop it being the go-to form of auth for ssh. Again, that was just an example of your password being stolen by the network you are connected to. I’m not here to discuss how to or if you should be using personal accounts on work equipment.
I’m also not going to discuss the merits of someone elses talking points. I didn’t even open that link.
So the fact that LITERALLY EVERY public key auth up to this point in history except for a very very limited few has been broken/updated isn’t a sign to you? Why are you so willfully ignorant here? NO encryption method is perfect… NO Authentication method is perfect.
Good thing everything I’ve talked about has been about Public Key Authentication and the traits that those have! Almost like being such a thing would have common traits between them that would not change!
Just like the challenge/response must be transmitted in a way that the server accepts it as a valid answer… Platitudes like this mean nothing and show that you do not understand any of the fundamentals happening here. Public Key Encryption is fundamentally 2 entangled passwords and a challenge (random generated known) on session start. There’s 0 reason that the passwords couldn’t just be an actual password for the private side, and the hash the public key. You need to read up on implementation of these things.
I literally said this so many time already it’s getting sad that you are arguing so disingenuously. You don’t HAVE to transport the password at all in password-based authentication. You can transport a hash(password+challenge) just like what passkeys would be doing.
No you’re not, and now I’m walking away from this discussion. I can’t have discussions with people who outright lie.
The best password implementations would do what I’ve outlined several times now… The worst passkey implementation could simply challenge with the same or no value at all which would allow replay (gasp! like bad implementations of passwords! almost like they are basically the same!). Like YOU admitted, you can’t control the site implementation. I’ve said it repeatedly that the best possible passkey implementation is WORSE than the best possible Password implementation. However, the worst passkey implementation is likely better than that worse password implementation. Kneecapping those of us who actually implement properly… That’s dirty.
And you’ve outlined none of your own. What productive communication this has been. It’s literally the same parroted talking lines that every fucking one of you “passkey” fanboys spout without any functional knowledge of what happening.
Go look at how all Public Key Encryption works. TLS is sufficient to understand it. https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
Nothing stops step 4 from being the hash of a password, step 5 being you applying your password. Literally nothing. Passkeys are not significantly different than passwords from a best implementation standpoint, and actually introduce a number of problems that passwords do not have. It’s all about implementation and everyone who is lazy in implementing strong password authentication code WILL be lazy implementing PassKeys.
Yeah you’ve already admitted that phone user’s don’t have a choice… and the vast majority of people’s only significant interaction with the internet in a day is their phone. So where’s the options for those people? Right… I’ve asked that like 3 times now and you’ve failed to answer.
I’m tired of you putting words on my mouth and needlessly insulting me in a genuine conversation. It’s just sad.
For example: I never said users dont have a choice on Android. You did.
I said my chosen Passkey manager has not yet implemented Passkey support. Nordpass, Enpass, 1password, and Dashlane are all examples of non-google passkey managers you can use right now on Android. You just couldn’t be bothered to look for anything but what was stuffed in your face for you.
Enjoy your rambling, I’m done here.