Hacker News Reader

Comment by malandrew | Hacker News Reader

Source visible? How are keys exchanged? How do you make sure the person you are sending the file to is in fact that person and not someone else?

View on HN

> How do you make sure the person you are sending the file to is in fact that person and not someone else?

The same way banks do "email money transfers": they email the recipient their pairing token. The logic being, if you can get into X's email, either you are X, or you're acting on their behalf. (And these types of services are used rarely-enough that if X has their email compromised, the sender will have already heard about it.)

> How are keys exchanged?

And this is why I said "pairing token" above--it seems like both clients have to be running at the same time for the transfer to progress, so presumably it's something like an ICE[1]-enabled TLS session between the two computers.

[1] http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...

They say key exchange is by Diffie-Hellman, and authentication is by validating fingerprints.

http://www.wireover.com/security/

"WireOver uses what we believe are the most appropriate, safe, up-to-date, peer-reviewed crypto primitives, implementations, and parameters [...] Fingerprint Algorithm: MD5"

I fear this page was written with a straight face :(

There's a tradeoff between collision resistance and fingerprint string length. We chose MD5 because people are comfortable with it in ssh, it's a shorter string to verify than something like SHA-256, and because we planned to make your peer's entire public key base64 available if you really wanted to go that extra mile (currently not available).

What would you prefer personally: (1) MD5 fingerprint for convenience AND entire peer public key base64 available if you really want; vs (2) just a longer SHA-256 fingerprint.

If you just want a shorter string, I'd prefer truncated SHA-256.

Yes, this is the correct way to get a shorter hash. Using MD5 is a terrible idea.

We're changing it.

Good call.

I'm confused by their claim of hashing and THEN salting authentication codes.

    On the server-side, we don't store the authentication
    code in plaintext. We hash it with PBKDF2 / SHA-256,
    salt it, then store it.

It's a salted hash. That page is corrected, thanks.

I wish they'd explain this "fingerprint" system that secures Diffie-Hellman against the man in the middle. e.g. how are fingerprints exchanged? If you can exchange anything truly securely, you can exchange good old fashioned public keys. If you can't exchange something securely you can't stop MIM attack.

It works like ssh. When you send or receive securely, you can see a fingerprint of your peer's public key, and a fingerprint of your own public key. Your peer sees these too.

To mitigate MITM attacks, ask your peer for their public key fingerprint using something other than WireOver: phone, SMS, email, PGP email - whatever you're comfortable with. That's your "second factor of authentication".

Your approval is cached so you only need to do it once.

We'll better explain this on the website.

No PGP key or contact email on the security page?

There's a PGP key on the contact page: wireover.com/contact

Reply on news.ycombinator.com