password storage Skip to main content
https://support.okta.com/help/answers?id=9062a000000xzuuqaw&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
w bw b 

password storage

Hello,

Can you confirm that all password stored at Okta, are not readable by anyone ?
I found this paper : https://www.okta.com/sites/default/files/Okta%20Technical%20Security%20Whitepaper.pdf
Which explain the password verification is made using hashing.
But it doesn't mention that the plain text password is not stored at Okta. 
We need it for our legal department.

Thank you for your help
 
Best Answer chosen by w b
David HoosDavid Hoos (Okta, Inc.)
SWA is Okta terminology for password vaulting. In an SWA configuration, a user enters a username and password for an app (e.g., Facebook), and Okta stores the credentials (these are stored in cloud, on our servers). When the user subsequently accesses the app, Okta posts the stored credentials to the app’s login form, automatically signing in the user. As described in the Key Management Service section, app passwords and other sensitive data are encrypted with a customer-specific symmetric key before they are stored. SWA is typically used for SaaS applications that do not provide support for federated single sign-on. Because Okta recognizes an app’s login form, SWA provides excellent protection against phishing attacks; a malicious login form will not “look the same” to Okta, and the user’s credentials will be safe.

All Answers

David HoosDavid Hoos (Okta, Inc.)
SWA is Okta terminology for password vaulting. In an SWA configuration, a user enters a username and password for an app (e.g., Facebook), and Okta stores the credentials (these are stored in cloud, on our servers). When the user subsequently accesses the app, Okta posts the stored credentials to the app’s login form, automatically signing in the user. As described in the Key Management Service section, app passwords and other sensitive data are encrypted with a customer-specific symmetric key before they are stored. SWA is typically used for SaaS applications that do not provide support for federated single sign-on. Because Okta recognizes an app’s login form, SWA provides excellent protection against phishing attacks; a malicious login form will not “look the same” to Okta, and the user’s credentials will be safe.
This was selected as the best answer
g bg b
This doesn't appear to answer the OP's question, which I interpreted to mean readable by anyone except the owner of said password(s).  If so, this hasn't been addressed above, and my auditors are asking as well.  Can someone please answer?  The "customer-specific" symmetric key isn't a control for this, per se, unless that's a key held only by that customer.  But there was no key exchange when we purchased, and no gateway in our infrastructure that would broker such an exchange.  So unless our passwords are that key, or a spawn/component of that key, I believe the answer to our questions is, no, this is not necessarily readable by the owner only.  Are they?

Thanks.