Hacker News Reader

Comment by dchest | Hacker News Reader

If I read it correctly, this is how a file token is generated, which is supposed to be secure:

     file.id = md5(file.name + (Math.random() * 1000));

First of all please do not use MD5 for anything anymore, it has known collisions. But you shouldn't also use any hash functions here at all: just generate a long enough random token. Math.random is not a secure PRNG, use crypto.randomBytes in Node or window.crypto.getRandomValues in browsers.

PS And multiplication by 1000... is it just for fun?

View on HN

Thanks for scrutinising the codebase! You are absolutely right that there is no need for creating a hash. This was just plain laziness on my part. I've created an issue (https://github.com/remie/YouTransfer/issues/101) to change the token generation.

Just to reiterate what dchest said, you should never use MD5 anymore, even if you do intent to hash something. MD5 is is broken and should not be used for anything anymore.

> MD5 is is broken and should not be used for anything anymore.

With the possible exception of demonstrating brokenness in hashing algorithms ;) (Sorry, couldn't resist!)

What about Gravatar?

Of course, you'll have to use whatever the third-party API uses, which includes Gravatar, but don't use it for anything under your control.

Replace with:

- BLAKE2 if you need a fast cryptographic hash function (e.g. for hashing file contents)

- SHA512 (or SHA256, or SHA-3) if you want a standard cryptographic hash function that is available in your programming language libraries

(Speaking of Gravatar, their use of md5(email) or even more secure hash function won't help protect email addresses against dedicated attackers, as it's easy to iterate over billions of them in seconds, just like in the stories about password cracking you hear, but it works as a simple anti-spam measure.)

Please just stop using it? It's the feature no one asked for.

I am not a very important person but I certainly ask for it, and I'd like you to stop discarding me and my "kind" as "no one".

Do you ask for that with the awareness that gravatar then gets to track your presence around the internet for the cost of a tiny picture?

I would rather have less ad tracking pixels on someone elses websites if possible, but I am genuinely interested in the value that gravatar provides to people who like the service.

There's a lot of things that can track presence around the web and gravatar's not one of them. Iff you decide to implement gravatar without mirroring their images, avatars are indeed loaded on their first query (and not subsequent ones) and, god knows what they're doing with that information ohgod. They certainly can't "track my presence around the web", though - no js means no fingerprinting, no tracking cookie, nothing. Juuuust a blind IP address.

But the recommended way is to prefetch the avatars directly from your server and offer them on your own cdn.

As for the value it provides, well for one thing I pretty much never have to upload my avatar to websites anymore - it's an avatar attached to my email addresses instead and that's very nice. Of course I'd prefer a proper identity protocol but nobody's working on one. If you want to, be my guest...

I think we disagree on one basic topic, I dont want an easily distinguishable identity to track across the internet.

I would rather external actors (say gravatar does nothing wrong) not be able to identify which email address I use on a site they do not own, and not be able to track my user signups by something that might be public information, which generally a site does not advertise.

It just feels wrong.

Unlike every actual tracker on the internet, Gravatar is opt-in. Things like google analytics, facebook like button/tweet button etc, they are all opt-out.

MD5 is is broken and should not be used for anything anymore.

Actually, HMAC-MD5 is secure.

It's a stretch to say it's "secure".

Yes, there aren't any known attacks right now, but since MD5 itself already has practical collision attacks against it, there isn't any good reason to use HMAC-MD5 in a new cryptosystem when there are better alternatives.

---

Supporting evidence: new versions of OpenSSHD do not use HMAC-MD5 by default anymore: it has to be enabled manually.

  The default is:
  
  umac-64-etm@openssh.com,umac-128-etm@openssh.com, 
  hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com, 
  umac-64@openssh.com,umac-128@openssh.com, 
  hmac-sha2-256,hmac-sha2-512

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/...

Good on you for taking the criticism well.

This doesn't seem like a "create an issue on github" problem though. Surely it is a push a patch today problem?

Working on it as we speak! I'm currently running the tests and hope to have a 1.0.2 hotfix ready by lunch.

EDIT: The 1.0.2 hotfix is now available with the token generation fix as well as 2 other enhancements.

Great! Make sure it's long enough: at least 16 bytes (32 hex characters) if you want to keep compatibility with current tokens, 32 bytes (64 hex characters) ideally.

I've opted for the 16 bits version right now as it fits better in the UI. There will be an additional issue to deal with improving the bitrate as well as making a suitable UI for it.

EDIT: I'm using `crypto.randomBytes(16).toString('hex')` to be precise

I hope you meant 16 bytes :-) If so, it's fine.

Edit: yep, 16 bytes.

And it's done. The 1.0.2 hotfix is now available with the token generation fix as well as 2 other enhancements.

Don't worry, it's not critical or anything. JupiterMoon just seems to be a bit of an entitled *ss.

I thought that HN policy was that posts should keep a civil tone.

My post was more civil than yours, so what's the problem?

Basically forcing him to put up a patch for an unimportant issue on the same day with your entitled comment was a really crappy thing to do.

Good stuff. Sorry if I came across as overly critical.

I'd use a uuid

UUIDs still need a sound source of randomness.

RFC 4122¹:

6. Security Considerations

Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.

Do not assume that it is easy to determine if a UUID has been slightly transposed in order to redirect a reference to another object. Humans do not have the ability to easily check the integrity of a UUID by simply glancing at it.

Distributed applications generating UUIDs at a variety of hosts must be willing to rely on the random number source at all hosts. If this is not feasible, the namespace variant should be used.

① https://tools.ietf.org/html/rfc4122#section-6

UUIDv4 is the only version of UUID anyone should ever use, and it should be generated with a secure PRNG, so using UUIDv4 is fine for this purpose (it has 122 bits of entropy).

You’ll excuse me if i believe the text of the RFC over some unsubstantiated claim from some person on the Internet. Expecially regarding a security issue, where the RFC explicitly says it’s not secure, and you go “naah it’s fine”. The RFC could easily have said “only use UUID version 4 as secure identifiers”, but it didn’t; I choose to believe that it does this for a reason.

Reply on news.ycombinator.com