<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D50Z00008G7UggSAFOkta Classic EngineAdministrationAnswered2025-07-27T09:00:12.000Z2017-06-22T21:03:59.000Z2019-05-10T04:41:49.000Z
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


  • david.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.
    Expand Post
    Selected as Best
  • david.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.
    Expand Post
    Selected as Best
  • gb (Customer)

    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.
    Expand Post
  • amvov (amvov)

    I second that. Why has no one answered the question?

  • ypuwu (ypuwu)

    Okta have avoided answering the question because they do not use secure password vaulting like password managers do. When you enter an SWA password you can clearly see it being sent in plaintext (over TLS) to Okta servers. Secure password vaulting would instead encrypt this value before it is sent, so it is not possible for anyone to view the password without the key it was encrypted with.

     

    If Okta had this functionality we could end our subscription to LastPass instead of running two services for the same problem.

    Expand Post
This question is closed.
Loading
password storage