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

Since my other comment got downvoted for unknown reasons I'll attach the WARNING here again:

Be aware that Inky uploads your imap password to their servers (see their FAQ). This is probably due to incompetence rather than malice but if you care about your e-mail password you should refrain from installing this software. If you have already entered your imap password into Inky you should change it ASAP.




The password is encrypted client side!

-----


That's meaningless. It opens a whole range of attack vectors for absolutely reason. No least your inky password (which they presumably use as the key). They allow a minimum length of 6 chars on that, which can be brute forced within hours on todays hardware.

They very clearly have no idea what they're doing (security-wise), consequently this is very likely not the only fatal flaw in their implementation.

-----


Easy account sync between devices is a good enough reason for me. It can be implemented securely, so in general I don't see a problem. Hey, Google Chrome syncs saved passwords, online password vaults like LastPass do this too, are they security-incompetent too? Don't know what hash function and encryption they use, but I think it's possible to pick/configure them so that brute-forcing even 6-character passwords is impractical.

-----


If you're willing to gamble your imap password on their undocumented process then that's fine.

I posted my warning because I think most users are not even aware that they're sending their password to inky and the implied risk. Also inky does nothing to educate them (a handwavy marketing-blurb buried in the FAQ does not count).

Sorry but comparing inky to LastPass and Google is laughable. Google is trusted because it's Google. LastPass is trusted because their process is extensively documented. If you plan to casually juggle your users crown jewels for a convenience-feature then you'd better fit into one of these two categories.

-----


Yep, the process needs to be transparent, documented and verifiable. Until it is, good idea to warn others!

-----


Client side encryption is only useful when the application is open source. Otherwise, we've no idea if there is a back door in the application and a signal that their servers can send back to the client to inform it to send over all of your login details.

Hushmail were forced by their government to backdoor their system for this purpose. What's stopping the same thing from happening to Inky?

-----


Right, but they also store the decryption key -- your Inky password. Which is (presumably?) encrypted… somehow? Maybe?

-----


This would be nice to know, because they're serving as a password-management app for all of your email passwords.

Presumably, they would not store your Inky password as well -- instead, they'd store a secure hash, not MD5 or SHA-1, which are built for speed, not security....

-----


It's more complicated than that. Please see my comments on security elsewhere in the thread. We store a password verifier object -- that's akin to a secure hash, but our authentication model offers better guarantees about protection from man-in-the-middle attacks.

-----


See my comments on security elsewhere in the thread.

-----




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

Search: