Hacker Newsnew | comments | show | ask | jobs | submit login

Here are some clarifying points on security issues. We wrote up a FAQ for the website, but it's not in the prod version of the site yet. Short version: we really care about this stuff, have worked with cryptography and other security experts, and are happy to explain what we're doing. The analogy to LastPass elsewhere in this thread is apt; our techniques are similar and we'll document what we're doing so you can evaluate them. Here's a thumbnail version:

Inky uses SRP (http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) to authenticate to the server that stores your credentials. This means that Inky proves to the server that you know your password without actually sending any bits of the password. Deriving the password from the stored password verifier object is thought to be a computationally hard problem, in a similar (number-theoretic) sense that, say, RSA is thought to be hard to break without knowing the password.

Your IMAP/POP passwords and other secure information are encrypted with a key derived from your Inky password. Since we don't know the Inky password, we don't know your IMAP/POP passwords. To add entropy to the encryption key, we use PBKDF2 key stretching. (As an aside: we can't reset your password since we don't know it; that's why we let you set up security question that lets you reset it from that machine only)

About not warning about self-signed certificates: this is obviously a trade-off between on-boarding simplicity and security. When you approve connecting to a site (which we tell you involves sending your password), you implicitly accept the site's X.509 certificate if it fails to validate. From that point on, however, we require the signature to match the certificate you accepted when you added the account; otherwise, we won't connect and we'll put up a warning. I'm personally interested in Tervor Perrin's work on TACK as an alternative to the well-known problems with the TLS trust hierarchy. (These problems have been discussed here extensively.)




Thank you for clarifying this. Your notes make me feel much better about sending you my password, and I'm glad you thought about self-signed SSL certificates too.

I still would like a warning to show up before I allow connecting to the server if it presents a self-signed certificate. Even something like this could get the point across:

    +------------------------------------------+
    | ======= Inky security warning ===========|
    +------------------------------------------+
    | Nobody's verified the identity of the    |
    | people who operate this mail server. Are |
    | you sure you want to send your password  |
    | to this unknown mail server?             |
    |                                          |
    | [Yes, send my password, and remember     |
    |   this mail server's fingerprint in the  |
    |   future]                                |
    |                                          |
    | [No, do not continue]                    |
    |                                          |
    | [More details...]                        |
    +------------------------------------------+

-----


We'll certainly make it clearer. We've gone back and forth on this internally (design/simplicity vs security/clarity). I agree it should give you some kind of indication that it's not a CA-signed certificate. I'd also like to show EV certificates differently, though I'm not sure many providers offer them yet for mail servers.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: