agrinman

You can put links in the body of the request, most mail clients should render them without a problem

Thanks! Oops, fixing the link now. We simply just pass along our at-cost price for sending an SMS via Twilio: https://www.twilio.com/sms/pricing/us.

Re: customization, we're quickly adding more customizations like colors/images, etc. Currently you can add a logo for your company, and customize all the text on the approval (approve text/reject text/title/body/etc). You can also specify redirect on {approve, reject} links to take the user somewhere after they answer the prompt.

Oops that's an outdated link, will fix asap. In the mean-time here is the spec: https://github.com/approveapi/openapi-spec

Hey -- one of the creators here, thanks for your comment. We definitely don't want to price out companies from using our service so we are listening carefully.

I also want to mention that we do support volume pricing, so if you want to send lots of approvals per month we can work together on a price that makes sense for your use case -- just reach out to us at support@approveapi.com.

I don't know about 1 but definitely agree with you on 2.

You could make validation part of the workflow (before you can even "say yes", you need to scan a QR code for example). You might say this is also not good UX and I wouldn't disagree. Cryptography + good UX is a hard problem.

It seems like you do not verify the public key of the new device (client-side) before encrypting the authenticated device's private key to it?

Your server can then impersonate a "new device", generate an ephemeral key pair, send the public key to all the user's authenticated device and perhaps trick the user into encrypting their private key to it. One way to prevent this is to show some sort of fingerprint on both the new device and the authenticated device proving that the public key is the correct one.

Does this device support U2F?

On Android it works for any site that uses the standard U2F polyfill and allows the chrome/android user-agent. You can try it on your android phone at https://u2f.bin.coffee.

On iOS it works for Google logins, see the blog post here: https://krypt.co/blog/posts/use-google-advanced-protection-w....

It does for Google logins, see the blog post here: https://krypt.co/blog/posts/use-google-advanced-protection-w...

Hopefully other sites support iOS based callbacks soon.

xkcd agrees: https://xkcd.com/2030/

<html></html> and perhaps netlify.com? I found it super simple to deploy a static jekyll blog site with them.

I think the content is getting better, and will continue to improve with time. It makes sense that it starts out geared towards young/new developers.

This is a very cool approach to building a developer community: let developers contribute directly to the platform, both in code and in content.

It looks like there's some intermittent failure with the high number of incoming requests -- sorry! Try again and it should work :)

Hey HN -- one of the creators here. I saw a few people mention this in the comments and want to re-iterate: this is NOT a bug on GitHub. This is a feature of Git that GitHub has to support because we often need to push commits on behalf of other users.

However -- this does illustrate a clear reason why it sometimes makes sense to PGP-sign your releases/commits.

It also helps that most "lunch" places put calories up (at least near where I work). You can at least figure what the "best choices" are. Ordering ahead is neat trick!

I agree it's not that sensitive...but I guess that's because I'm biased and released all my own data willingly :)

Really love the idea! The extension is a bit buggy for me on facebook.com but otherwise seems to run smoothly.

Krypton supports bluetooth for so even if SQS and SNS are down -- you can still SSH. We'll also shortly be rolling out USB support just incase bluetooth also happens to not be working :)

There isn't a good division between personal and work use yet -- this is something that's coming (i.e. multiple teams/keys support).

Yes! This is coming in the next few months. You'll be able to require multiple admins to approve production releases or really lock up sensitive machines. Supervised access (requesting short-lived access to a server in real-time) is coming too!

Hey HN, we’re happy to announce that Krypton for Teams is now available! Thanks for all your support when we debuted Krypton Core, your early feedback strongly influenced the Teams product.

Krypton for Teams builds on Core to make DevOps key management easy and secure by default. We designed Teams to be cryptographically end-to-end verified using signed hash chains. Even if our infrastructure is attacked your team data cannot be altered.

Looking forward to your feedback!

Glad someone is working on this!

One of the reasons we built PGP signing capabilities into Krypton [0] is to make it easy for anyone to sign their Git commits/tags. Almost nobody uses this awesome feature of Git. We even ended up implementing parts of the OpenPGP spec in Swift [1].

0: https://krypt.co/docs/start/code-signing.html

1: https://github.com/kryptco/swift-pgp

"Zero Knowledge Encryption" is just a marketing term... I wish marketing would not cross wires with real crypto, it makes me skeptical that they really know what they're doing. They're not the only company doing this and they should be called out for it like spideroak [1].

ZKP[2] is real branch of cryptography and they do not use it AFAIK.

[1] https://spideroak.com/articles/why-we-will-no-longer-use-the...

[2] https://en.wikipedia.org/wiki/Zero-knowledge_proof

Your attack vector is correct, but Kryptonite is still a step up from existing solutions since you know exactly when your key is used and what host is being logged in to (the app does known host pining as well).

YubiKeys don't have a UI to show you what you're approving plus suffer the same problem you described. Most developers store keys as files on their machine which can be easily stolen (even if they're encrypted on disk) and used to authenticate to as many servers as the adversary likes without you even knowing.

If it was easy to setup (for you and all your team members) would it be something you'd value at work?

Any user-level process can actually obtain your decrypted private-key: https://blog.krypt.co/why-store-an-ssh-key-with-kryptonite-9...

We just release Kryptonite (https://krypt.co), an HSM for your SSH private key on your phone.

The private key never leaves your phone. Pair your phone with your computer to create a secure channel (channel is encrypted + signed with session keys only known to your computer and phone). Every time you SSH, the computer calls out to your phone over this channel and asks you to approve a signature.

SSH logins with simple push notification approvals. Code is public: https://github.com/kryptco.

This is not cryptographic though.

We'd love to do an integration with keybase.io: i.e. add your Kryptonite SSH public key to your Keybase profile.

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 less secure than your laptop. On the phone, apps are sandboxed and the private key never leaves the Kryptonite sandbox.