221–227 of 227 posts
i'm reminded of theo deraadt's answer to a slashdot question back in the say about making a bootable openbsd firewall on a floppy. his response was along the lines of, "firewalls are supposed to be among the most reliable things. floppy drives are among the least reliable things."
Earlier quoted context omitted.
>> Every application on the phone is sandboxed Note that you are trusting this app with your private key. While other apps are sandboxed away from having access, all it takes is one update to the app to sneak away your private key to any remote server. You have to trust the publisher of this app, including their entire chain of source code repository management and app build/release process. It takes a single instanc…
> Note that you are trusting this app with your private key. While other apps are sandboxed away from having access, all it takes is one update to the app to sneak away your private key to any remote server. You have to trust the publisher of this app, including their entire chain of source code repository management and app build/release process. It takes a single instance of a malicious person inserting code that s…
The fact remains that app installs are bundles whose base source could come from anywhere. There's no guarantee that what you install from an app store was built from their GitHub. On a non-jailbroken iOS device, you're installing a closed-source binary with no inspection possible. I believe you could build your own Android apk from their GitHib, but how many users would ever do that (let alone rebuild it on every update)?
As I mentioned, I suspect that the first attack against one of the major password managers will result from a commit to the official repository (ex: GitHub). Users are not looking at every commit to GitHub before updating an iOS app to make sure that the latest version doesn't have a backdoor.
At the end of the day, you must trust the app publisher with your unencrypted data within the app. Anyway, for this ssh product, I wouldn't be all that worried. Password managers though... I'm waiting for the first attack to happen, at which point I can point to my HN history to show I saw it coming. ;)
Earlier quoted context omitted.
license :( this exact thing is on my devs teams backlog. if you figure out a good license it would be AMAZING for us.
GPLv3 should be enough for an app; AGPL adds additional protection for server-side/self-hosted projects. https://softwareengineering.stackexchange.com/questions/1420... The MuPDF app is available under AGPLv3+. https://itunes.apple.com/us/app/mupdf/id482941798?mt=8 You will catch some flak for discouraging free commercial re-use. If you see your app or portions of it as more of a library for others to use then LGPL i…
Fixed that for you.
Earlier quoted context omitted.
The lack of a license leaves this very unclear.
GitHub's user agreement allows for the free use of any code posted in a public repo.
GitHub user agreement allows other users to view and make copies of your content on github but not for "free use" in general.
https://help.github.com/articles/github-terms-of-service/#5-...
In terms of possible compromise, I rate the possibility that my phone is compromised way higher than my laptop. Adding a factor is a good idea in terms of security (not in terms of availability and ease of use, but definitely in security), but replacing it entirely... No. Why'd I even want to remove id_rsa? What's the problem being solved here?
The problem is that your private key stored in ~/.ssh/id_rsa can be read by any user-level application. The private key is even vulnerable if you passphrase encrypt it. See our deep dive into the threat model: https://blog.krypt.co/why-store-an-ssh-key-with-kryptonite-9... This is why we move it off the computer and onto a phone. The security is comparable to using a Yubikey. I'm not sure why you say your phone is le…
> At the core, phone operating systems are built with better sandboxing than their desktop counterparts. This is why security experts like Matt Green recommend phones for your most sensitive data.
Having a better sandboxing is not the same as having a "safe sandboxing". How secure is the application once an attacker is able to compromise the sandboxing?
IMHO the rest of the threat model "deep dive" has no value once we take that attack scenario into account.
What about a non-dictionary based 20chars password protecting your private key, or storing your SSH key on an OpenPGP Smartcard in a USB token, a Yubikey or a Nitrokey (www.nitrokey.com)?
I believe that it would be much more secure than application whose security model is based on the sole sandboxing.