Best practices for storing long-term access credentials locally in a desktop application?

I’m wondering how applications like Skype and Dropbox store access credentials securely on a user’s computer. I imagine the flow for doing this would look something like this:

  1. Prompt the user for a username/password if its the first time
  2. Acquire an access token using the user provided credentials
  3. Encrypt the token using a key which is just really a complex combination of some static parameters that the desktop application can generate deterministically. For example something like:
value = encrypt(data=token, key=[os_version]+[machine_uuid]+[username]+...) 
  1. Store value in the keychain on OSX or Credential Manager on Windows.
  2. Decrypt the token when the application needs it by generating the key

So two questions:

  1. Is what I described remotely close to what a typical desktop application that needs to store user access tokens long term does?
  2. How can a scheme like this be secure? Presumably, any combination of parameters we use to generate the the key can also be generated by a piece of malware on the user’s computer. Do most applications just try to make this key as hard to generate as possible and keep their fingers crossed that no one guesses how it is generated?

OAuth2 – Sending a hash of your client_secret when using the client credentials grant instead of the secret

I’m working on an API that I’d like to be accessible internally by other servers as well as devices that I consider both as confidential private clients. Devices are considered private clients because the client_secret is stored in an encrypted area that prevents from unauthorised readout and modification (even though nothing is never bullet proof)

For auth, I’d like to use OAuth2 with the client_credentials grant that seems to be a very good fit for these use cases. However I’m wondering how flexible is the standard regarding sharing the client_secret.

Basically the RFC doesn’t say much about sending your client id / client secret, it just offers an example here: which is very simple by using the following header Authorization Basic: base64(client_id:client_secret)

In my opinion, it could be slightly more secure by computing a hash:

  1. the client requests a random to the server by sending their client_id
  2. the server replies with a random code (valid for like 10 mins, just like an authorization code)
  3. the client computes a hash = sha256(client_id, client_secret, code) and asks for a token
  4. the server computes the same hash, compares the client hash with the computed hash and sends an access token if they match

It would add an extra layer of security in case https is somehow broken or if anyone is able to read the header somehow.

However it doesn’t seem very OAuth2 compliant and I don’t really like re-inventing a standard. Another option would be to create my own extention grant, I’m just wondering if it’s really worth it, like no one seems to have done this.

Also, if I want to share my API with a 3rd party app, not sure it’s a good thing to force them into using something non really standard.

How do enterprises deal with SSO and Google backing up WiFi credentials?

Single Sign On in a company means that you have one set of credentials for all the services the company uses / provides to their employees.

Logically, these credentials might also be usable for Wifi.

  • Benefits for the employee: Only one password to remember
  • Benefits for the company: Wifi access can be revoked on a per-user basis. Administration is centralized.

Are there real-world examples and guidelines how to deal with the fact that Android smartphones store Wifi passwords on Google servers by default? Doesn’t this give Google access to the full digital identity of an employee and access to the company’s internal services?

  1. Asking users to turn this feature off on their phones seems to be error-prone and might be forgotten. Especially after a smartphone change.
  2. Prohibiting users to log in the company Wifi from their own devices is impractical and will probably even be ignored.
  3. Only company-managed phones are also no option, because of point 2.

Is SSO a bad idea concerning Wifi? How do large enterprises, universities, … but also small companies with less “enforceable” rules handle this?

How to securely access oracle system user credentials from my installer

We have a installer that we have built using scripts. When we start the installer, it asks for the database system user and password, which it needs to create application users. We do not want the user doing the installation to know the system user password. Hence we are looking for ways in which installation can go through without sharing the system user password. Few things we have explored. Encrypting the system user password using an utility. This is not very feasible, considering that we have to embed the key in the installer, which is not obfuscated/encrypted(basically user can read it by opening it) Obfuscating the utility used for encryption and installer. This was ok, but it is still unsafe, as obfuscation itself is not fool proof.

Is there any other way , this can be handled. Is there an Oracle API, that we can use? Please suggest.