credentials stored in plaintext

[hadmut]

Is there a good reason for storing the authorizations in plaintext instead of some hash?

Usually it is a no-go to store passwords/credentials as plain text.

[duyquangnguyenhac]

Hey @hadmut, I think you're referring to the S3 module that I built. First of all, it's a good issue to bring up, and there might be room for improvement, feel free to contribute if you have a better idea. I did it as such since it was one of the recommended practices on the AWS S3 API. The AWS documentation were also storing credentials on a local directory anyways and I mimicked that behavior for this module. I can't think of a way to properly hash these password, since if you have accessed to the hashing algorithm uploaded to the repo, isn't it useless since you can reverse the hash?

[hadmut]

Hi James,

No, I was using it locally (putting it in a docker container) and noticed, that it creates an sqlite3 database, where I found the credential in plaintext.

However, it doesn't seem to use usernames and thus it could be an indexing problem, i.e. when credentials are stored as a hash (e.g. bcrypt) and there's no username, the server would need to try all (technically an unlimited number) hashes instead of seeking.

Is the authentication mechanism a detail of this particular implementation or given by the gem standard?

[NobodysNightmare]

As far as I can tell this is the standard way. E.g. API keys for rubygems.org are also just API keys and have no username: https://guides.rubygems.org/rubygems-org-api/#api-authorization

[hadmut]

No, I think there is some misunderstanding.

Usually, the authorization string is something base64 encoded consisting of username:password, see e.g.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization
https://en.wikipedia.org/wiki/Basic_access_authentication

where the data in the authorization header consist of a base64 encoded pair of username password, where the username is used as an index in the the password database, and the password is sotared as a hash, where the index allows to find it.

So this looks as if the authorization header is not implemented correctly here.

[kyrofa]

@hadmut is right, the fact that these tokens are in plaintext makes a database dump falling into the wrong hands pretty tragic.