3 ms·
It seems that the fundamental problem here is Okta is sending passwords by design to execute a password sync. Typically, when you build an authentication system
by munchbunny 4y ago
It seems that the fundamental problem here is Okta is sending passwords by design to execute a password sync. Typically, when you build an authentication system, you design your code to not store the password in plaintext so that there is no possibility of the password being read back out of the system, but Okta isn't doing this because they need to be able to do password syncing.
If you're trying to do this right, the short answer is "don't try to sync passwords." Use federated authentication (such as OAuth), or just use different passwords.
Can someone fill me in as to why they can’t just store the password using something like bcrypt?
It's addressed in the last paragraph: "For Okta's part, the passwords are in clear text because there is no standard reliable protocol for syncing hashes, researchers noted."
I guess you either have to store the password in plaintext so they can do dynamic hashing operations on it, or transmit the password (via TLS hopefully) which is vulnerable to packet capture (or captured within the receiving app).
TLS (when securely configured) is generally considered sufficient protection for the passwords in transit because stealing the password out of TLS typically requires first compromising the TLS connection, in which case you don't even need the password because you can steal the bearer token and the bearer token doesn't require you to get past a MFA check.
Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them?
This question doesn't quite compute for me, do you mean provisioning as opposed to authenticating? There's no reason an identity provider would need to send a user's password to the user when trying to authenticate that user.
- jf 4y agoTypically, when you build an authentication system, you design your code to not store the password in plaintext so that there is no possibility of the password being read back out of the system, but Okta isn't doing this because they need to be able to do password syncing. Incorrect. Okta stores passwords as hashes. By default, random passwords are synchronized when an administrator sets up SCIM and enables password synchronization. If the administrator specifically configures SCIM to synchronize the real passwords, then the downstream system will only get the real password for a user after a user successfully logs in.
- tsimionescu 4y ago> > Are there any techniques for identity providers to authenticate people without storing or transmitting the users password to them? > This question doesn't quite compute for me, do you mean provisioning as opposed to authenticating? There's no reason an identity provider would need to send a user's password to the user when trying to authenticate that user. I believe "them" here referred to "identity providers" - that is, can an identity provider authenticate a person without that person sending their password to the identity provider? The response to that is yes, though they are not widely used - WebAuthn is a standard though that covers this - though in such a system there simply is no password. The idea that you would have a password but not send it to the identity provider makes no sense: the whole purpose of the identity provider is to recognize you. When using an IdP, you are protecting your password from the final website who only gets to see what details you allow the identity provider to share with them. If you trust the website more than the identity provider, you shouldn't be using the identity provider at all.
- blincoln 4y ago> The idea that you would have a password but not send it to the identity provider makes no sense It's possible to prove to a remote system that one knows their own password without sending the password (or an equivalent, like NTLM hashes). Secure Remote Password protocol (SRP)[1] is one specific implementation. [1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...