2

I need to set users up for subversion access, and we're currently stuck using htpasswd for our credential storage. If a user sends me an htpasswd record via email (or GChat / off the record?), what's the level of risk we're incurring?

Hashing would be done using the default htpasswd algorithm: htpasswd -n someuser

And some users would likely be generating their hashes with this tool: http://www.htaccesstools.com/htpasswd-generator/

So, there are three risks I'd like a professional opinion on. The risk or likelihood that ...

  1. .. htaccesstools and/or the connection between the two is compromised and that the attacker can guess what the credentials will actually be used for!
  2. .. the IM/email will be compromised.
  3. .. if the hash is known, that it can be cracked. (If we can assume the users pick strong passwords, what level of risk does htpasswd's default hashing (md5?) impose?)

But maybe more importantly, would a security-minded professional in my situation prefer this route? Or would he just pick passwords and tell the end-users their passwords over the phone?

svidgen
  • 711
  • 5
  • 13

2 Answers2

2

By default, the htpasswd utility tends to use an Apache-specific hashing password called "apr1" and documented here. It seems to be a custom construction that invokes MD5 1000 times. Assuming that there is no structural weakness in that construction, the attacker can still try out passwords at a rather fast rate. As documented here, an AMD R9 290X GPU is be able to compute about 11.5 billions of MD5 per second. Since each password try requires a thousand MD5 invocations, the attacker should be able to try 11.5 millions of passwords per second. This is quite fast, and one has to assume that a "normal user password" won't last very long.

Even a rather strong 44-bit entropy password will fall within a week of computations, with an attacker using a single off-the-shelf GPU.

Function identification is not hard since it is written in the hash string itself (e.g. it begins with $apr1$).

Personally, I'd use the phone. As @André suggests, PGP is also usable, provided that PGP is installed. Another option is to open an SSH-based shell account (this requires obtaining a copy of the SSH public key of the user) and storing the password in a file on that account (or the user pushes his htpasswd file there).

Emails may be fine if you can control the whereabouts of the email, which is hard in all generality, but can be made much easier in some cases. Namely, have the user send the email from his gmail account to your gmail account; presumably, emails sent from gmail to gmail don't travel unprotected over the Internet. However, since there is no security whatsoever in the email protocols, such an assumption cannot be made for just any email server.

(As a rule, it is better to assume that any attacker who bothers reading your emails knows quite a bit about what you do and what exchanged passwords are for -- after all, he reads your emails.)

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • "emails sent from gmail to gmail don't travel unprotected over the Internet": But some email client software may store them locally unprotected, as may do some IM clients who automatically store exchange logs for further reference, and this local copy may be found replicated on other / external media for backup purposes... +1 for the phone :) – WhiteWinterWolf Apr 24 '15 at 13:42
0

In general, you should take steps to prevent a hash from being exposed perhaps by using encrypted email or at least an encrypted connection. That being said...

I believe the risk of 1 (connection compromised) or 2 (email intercepted) happening is pretty low, and number 3 (solving the hash) is the part that matters the most, because if the answer to 3 is that the hash cannot be easily solved, then you shouldn't care as much about 1 or 2. I'm going to continue with Tom's 11.5 million tries per second calculation, but come to a slightly different conclusion. If you use only letters and numbers (62 characters), and you require a minimum of 8 characters, the average time to find a password is around 11 days. With a minimum of 9 characters, the average time would be approximately 2 years. If you add in just some of the special characters (18 symbols or 80 total chars), a random 8 character password would take on average 84 days to solve, and a 9 character password would take on average 19 years. If you make the minimum 10 random chars it goes up to 1500 years. Add as many more characters as your paranoia requires.

I have two thoughts regarding this:

  1. Since typically users store their Subversion passwords within their client, (they don't need to memorize it), then you can use generated passwords. If they are random passwords of at least 80 allowed characters with a minimum length of at least 10 characters, a compromised hash should not worry you.
  2. If the users are creating their own password and you only see the hash, you would have no way of knowing if the user actually generated the password properly according to your specified rules. So if you cannot guarantee that the actual passwords follow the required rules to create a safe-to-be-exposed hash, then you should assume your hashes aren't safe if compromised.
TTT
  • 9,132
  • 4
  • 19
  • 32