Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
I do have some thoughts regarding it now though:
- They say that if you lose your phone, you should remove the old public key and then create a new one and change it, but how will you do that, if your server responds to ssh key only?
- How is the generated key encrypted in in-app storage on android, since it never asks for a pin, nor can it encrypt anything with the device lockscreen pin since android 5 iirc? -
@JoshBent yeah i found it a few months ago. It has a few problems but its better than regular ssh keys. The main problems i have with it is on android the strongest key you can make is a 3072 bit key, as far as i know gpg keys arnt supported, and its only supported on devices with the keystore system. Which really that last one is a gripe and security win.
But i have a yubikey with 3 4096 bit keys on it for signing, encrypting, and ssh authorization so using my phone as one doesn't make alot of sense in my case -
devs30827yI don’t either like the concept of loosing access if I loose my phone. However something a bit similar could be cool. Like if instead of authentication for ssh, it was the firewall on the server. Then every times someone logs on, you get a notification and the possibility to block that ip in the firewall from your phone.
-
@PerfectAsshole @Linux now that I think of it, with yubikeys the rules are usually having one as a backup somewhere, so if you lose the other one (or it stops working), you can just login with the backup one, so maybe one should have a similar system with this too, though I don't think many have two phones where they can just bunker one away and this doesnt even allow you to securely backup them atleast on your resources, which would solve the problem entirely. Also an interesting read on the keys to consider is: https://krypt.co/faq/...
@PerfectAsshole I wonder how I can see if my device supports keystore and how does this handle the in-app storage saving, what is used for the key of the encryption, since it doesn't use any user input, so could the key be recovered easily then? The keystore method sounds a lot like the iOS implementation iirc and would be probably the way more secure way.
(Cont.) -
@devs as mentioned already by @lubekpl you can just put a call to a pushnotification api in the sshrc and it will get executed each time a successful login goes through
(Cont.) -
@FrodoSwaggins It's a balancing act I think in general, since both devices can be rendered open if infected, though if your mobile device does not allow root access, I doubt it can get the key even from the in-app storage, which is located in /data and not accessible without full root permissions. A desktop device though, has much more ways of exposing your key, which is anyway located in the home directory, where anything can access it. I just like the idea that they remove this fear I had for a while of some program just reading out the keys and then bruteforcing them. That would take a long time with just stupid bruteforce, but who knows how long a password lasts against a well mixed dictionary/leaked passwords base/.. attack for example and ssh keys don't have any mechanism that would prevent one from just trying to bruteforce it forever, until they have it.
(Cont.) -
@FrodoSwaggins
"Makes me very nervous in this day and age." you're not alone with that one either, I am very sceptical with new ideas popping up, especially ones that seem too good to be true, though some factors like full transparency, full open source etc. kind of takes a bit off, though I am pretty aware of "hidden in plain sight" too..
"I find it unlikely that the key would be too difficult to retrieve if somebody had the phone." that's another thing, it also saves the trusted sources like ssh does (https://krypt.co/docs/ssh/...), so an attacker that has physical access, could just open the app, look into known hosts and use the key to auth to those specific hosts (taking away the "well how would he know where I use my ssh keys at") -
Nothing to add in regard to @FrodoSwaggins, @Linux and @PerfectAsshole's comments.
They describe everything perfectly well.
@FrodoSwaggins good point, the zero day's (in combination with that agency) -
@JoshBent generally if you have a android phone released in the last two years you have it. But it won't install on google play if you don't have it.
The key store makes it pretty secure cause the only way to get the keys is to pull the chip like you would have to on a yubikey. So its not a horible idea if you have nothing better -
@PerfectAsshole that sounds great, it did let itself install, so that means my phone does have the chip needed? I tried to find some android api test, to check if I actually do, but can't find one, also the specs (LG G3) don't mention it anywhere.
Related Rants
Came across: https://krypt.co sounds interesting, because its like an additional 2fa for your ssh key, is locally encrypted, open source, well documented and transparent:
https://krypt.co/docs/security/...
Why is it not much talked about? sounds great so far, but maybe somebody can find the tick? or is using it himself?
random
key
ssh
ssh key
2fa