You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All data should be encrypted at rest, but sensitive data such as credentials most of all. CWE-256 and CWE-312 capture this security concern.
There are many reasons why plaintext storage is a bad idea, but to my knowledge these are the main ones:
Physical breaches are common
People lose their laptops all the time, and any data that is stored un-encrypted becomes instantly accessible. Credentials can be used to immediately escalate access to match the device owner's and this has led to numerous breaches of whole companies and government systems.
Even if the filesystem is encrypted as a whole (which is not something an userland application can assume), there's always the possibility that the device gets compromised while unlocked. It takes seconds to copy a credentials file, so the device owner may not even realise anything is wrong.
File permissions are weak protections
How often do people actually stop and take time to set up file permissions sensibly? The default on linux is 644 (rw-r—r–), which allows all users to read it. Even if we take care to set a more restrictive permission when the credentials file is created, the user may accidentally override it in a number of ways (how many tutorials out there say to run chmod -R 777 * as a quick way to fix access denied errors?).
There have been developed numerous exploits that can bypass file permissions. Not all filesystems even support this feature properly (there are people on FAT32 out there).
Admin users can easily bypass file permissions. Although locally they are meant to have elevated privileges, that doesn't mean they are entitled to impersonate another user on another system.
Finally, although this is more subtle, from a risk modelling perspective, it's a bad security posture to equate access to a dev environment (which can potentially be shared) to a specific user's registry access. For example, consider that the user may have a weak password set to access a dev box, because they think of it as a disposable experimentation environment, but uses 2FA to access Artifactory, because there's lots of sensitive assets there that they and others have published. By storing a user token in plaintext in that dev box, we're quietly downgrading security of the whole Artifactory instance down to just that one weak password.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
All data should be encrypted at rest, but sensitive data such as credentials most of all. CWE-256 and CWE-312 capture this security concern.
There are many reasons why plaintext storage is a bad idea, but to my knowledge these are the main ones:
chmod -R 777 *
as a quick way to fix access denied errors?).Finally, although this is more subtle, from a risk modelling perspective, it's a bad security posture to equate access to a dev environment (which can potentially be shared) to a specific user's registry access. For example, consider that the user may have a weak password set to access a dev box, because they think of it as a disposable experimentation environment, but uses 2FA to access Artifactory, because there's lots of sensitive assets there that they and others have published. By storing a user token in plaintext in that dev box, we're quietly downgrading security of the whole Artifactory instance down to just that one weak password.
Beta Was this translation helpful? Give feedback.
All reactions