This is a demo of an authentication approach that combines the familiarity of passwords with the security of digital signatures. Instead of sending passwords to servers, users derive cryptographic key pairs from their passwords and use digital signatures for authentication.
With PDSA, passwords never leave the client device in plaintext and even if the server is breached, attackers cannot impersonate users, so even if users reuse the same password across services the impact to other services using the same password is minimal.
dontdoxxme · 6h ago
> even if the server is breached, attackers cannot impersonate users
The weakest link is still the web platform, an attacker can change the JavaScript served.
> even if users reuse the same password across services the impact to other services using the same password is minimal
Failing to understand this argument, if an attacker wants to target the service, they can run the key derivation themselves?
They can also enumerate users because the salt is returned. It says the server should implement rate limiting to stop brute forcing, but that isn't going to help with simple password reuse.
danieltanfh95 · 4h ago
Are you referring to phishing attacks?
How would they enumerate users through the random salt? Also, are you suggesting that they try to recreate the private key and enumerate through all possible values of the private key…?
Edit: I get what you mean, you are suggesting that since the salt is returned the attacker can still attempt password replay by enumerating through simple values like 0000. That is true. This approach does not improve on that area. That being said, using derived salt would more or less make it much difficult for offline attacks, whereas API attacks can be mitigated with rate limiting, captchas and proof of work.
With PDSA, passwords never leave the client device in plaintext and even if the server is breached, attackers cannot impersonate users, so even if users reuse the same password across services the impact to other services using the same password is minimal.
The weakest link is still the web platform, an attacker can change the JavaScript served.
> even if users reuse the same password across services the impact to other services using the same password is minimal
Failing to understand this argument, if an attacker wants to target the service, they can run the key derivation themselves?
They can also enumerate users because the salt is returned. It says the server should implement rate limiting to stop brute forcing, but that isn't going to help with simple password reuse.
How would they enumerate users through the random salt? Also, are you suggesting that they try to recreate the private key and enumerate through all possible values of the private key…?
Edit: I get what you mean, you are suggesting that since the salt is returned the attacker can still attempt password replay by enumerating through simple values like 0000. That is true. This approach does not improve on that area. That being said, using derived salt would more or less make it much difficult for offline attacks, whereas API attacks can be mitigated with rate limiting, captchas and proof of work.