PastaGorgonzola

joined 1 year ago
[–] [email protected] 2 points 9 months ago

As a manager in software engineering: this! If I learned that one of my devs was wasting time like this, I'd want to know. Just make sure to stick to the facts.

[–] [email protected] 12 points 10 months ago

You can follow the steps here to use a previous version of the desktop app to extract the keys: https://gist.github.com/gboudreau/94bb0c11a6209c82418d01a59d958c93

The javascript didn't seem to send the extracted data anywhere, but I did disconnect from the internet while running the script.

[–] [email protected] 9 points 10 months ago (1 children)
[–] [email protected] 6 points 11 months ago (1 children)

Remote wipes are possible. Log into your Apple/Google account, figure out how to find your device, then perform a remote wipe.

[–] [email protected] 3 points 11 months ago (1 children)

If tomorrow's race goes on as planned and Stroll participates, that's tomorrow's race. If for some reason Stroll can't participate tomorrow, he won't escape this penalty.

[–] [email protected] 3 points 1 year ago

I was looking through this community because my daughter was recently diagnosed, but this comment hit a nerve.

I cannot stand socks that feel wrong, and no, I cannot explain what exactly "wrong" means. I don't own more than 1 identical pair of socks: each pair has a clear left and right sock, so mixing up 2 identical pairs is a nightmare.

[–] [email protected] 9 points 1 year ago

That's the part where the server doesn't story any information that an attacker could use to log in. The attacker would need the private key, which is stored inside a secure chip on your device (unless you decide to store it in your password manager). All that's stored server side, is the public key.

When you're using a password, the server will store a hashed version of that password. If this is leaked, an attacker can attempt to brute-force this leaked password. If the server didn't properly store hash the password, a leak simply exposes the password and allows the attacker access. If the user didn't generate unique passwords for each site/server, that exposes them further to password spraying. In that case an attacker would try these same credentials on multiple sites, potentially giving them access to all these accounts.

In case of passkey, the public key doesn't need to be secret. The secret part is all on your end (unless you store that secret in the managed vault of your password manager).

I do agree that your risk is quite small if you're already

  • using a decent password manager
  • doing that the right way
  • have enabled 2FA wherever possible
[–] [email protected] 28 points 1 year ago (3 children)

The biggest difference: nothing sensitive is stored on the server. No passwords, no password hashes, just a public key. No amount of brute forcing, dictionary attacks or rainbow tables can help an attacker log in with a public key.

"But what about phising? If the attacker has the public key, they can pretend to be the actual site and trick the user into logging in." Only if they also manage to use the same domain name. Like a password manager, passkeys are stored for a specific domain name. If the domain doesn't match, the passkey won't be found.

https://www.youtube.com/watch?v=qNy_Q9fth-4 gives a pretty good introduction on them.

[–] [email protected] 11 points 1 year ago (3 children)

Not sure what part you don't understand, but I'll try and help: Snopes (a fact checking website) shows that the way links are displayed nowadays (the new link presentation or new way links are presented) on X (formerly Twitter) lacks any sense -> snopes shows the folly of it.

[–] [email protected] 6 points 1 year ago (3 children)

Unless you have siblings. Then you're the less successful evolutionary branch that died out.

[–] [email protected] 3 points 1 year ago (1 children)

I’m going to have to stop replying because I don’t have the time to run every individual through infosec 101.

Sorry, but you're missing the point here. You cannot do anything with a password without storing it in memory. That's not even infosec 101, that's computing 101. Every computation is toggling bits between 1 and 0 and guess where these bits are stored? That's right: in memory.

The backend should never have access to a variable with a plaintext password.

You know how the backend gets that password? In a plaintext variable. Because the server needs to decrypt the TLS data before doing any computations on it (and yes I know about homomorphic encryption, but no that wouldn't work here).

Yes, I agree it's terrible form to send out plain text passwords. And it would make me question their security practices as well. I agree that lots of people overreacted to your mistake, but this thread has proven that you're not yet as knowledgeable as you claim to be.

 

Just following the rules

view more: next ›