Do you work in, or are you passionate about, application security (ie OWASP) or infosec?
Then we’d really appreciate your advice and guidance on a design pattern we’re considering to store Skill Settings - settings used to provide functionality for Skills - such as OAuth credentials or say login credentails - on home.mycroft.ai.
Ideally we’d like to encrypt the credentials on both the server and the Device (the Device - such as a Mark 1 - pulls the Skill Settings down from home.mycroft.ai).
Has anyone done something like this before? What would you recommend? Does key management make it harder?
Thanks in advance for any suggestions you may have.
I work in Infosec. What credentials are you referring to exactly? Our home.mycroft.ai credentials, or the method a Mycroft device uses to login and retrieve settings from home.mycroft.ai? (presumably an API token or something?)
It’s not so much the retrieval we’re looking at at the moment, it’s the storage on home.mycroft.ai itself. The path between home.mycroft.ai and the Device is encrypted, and we’re less concerned about encrypting credentials on the Device because this is generally less vulnerable to exploitation.
It’s more what our best practices should be with credential storage on home.mycroft.ai itself. For instance, should the credentials be encrypted with a different key per-user, which could become significant overhead over time, or a single key, which would be an issue if that key were ever compromised.
The usual secure standard for password storage is salting with a unique, randomized string (unique key per-user) that is stored separately, and hashing the resulting value. Using the same key/salt for each password is less secure. See the section on “Adding Salt” here: https://crackstation.net/hashing-security.htm
There’s a good salt length recommendation on that page I linked:
“A good rule of thumb is to use a salt that is the same size as the output of the hash function. For example, the output of SHA256 is 256 bits (32 bytes), so the salt should be at least 32 random bytes.”
It would be nice to have an update on this topic when it’s been addressed (hopefully soon). the implication that our passwords are being stored insecurely is a bit concerning.