The difference is that neither the original nor mine actually submits the secret to the server. I went to great lengths to avoid actually doing it, it's still a bad idea to send a password to my page but at least you can check the source and network traffic and see that it's only checked with JavaScript and a hash is checked against the HIPB password site.
This supposed joke site sends and processes the key on their backend. At least it looks like that, I have not tried with a real key.
One of the best things you can do is generate a key per device, not per person. That way if you lose your phone you just revoke that key and not the one that you use on your tablet, work laptop, home desktop, etc.
Bonus points: monkeysphere and certificate based auth are two other great solutions for making sure the ssh server you log into is not doing a MITM on initial connection (you know, the part where it asks you to manually verify the fingerprint of the server key and you likely just hit y instead).
Forwarding your ssh agent to a host that you don’t know for certain is not doing a MITM attack on you can be devastating, as is entering a password into same.
But that way you can only use each key on that one device. E.g. No starting a private conversation on your phone and then continuing it on your desktop later.
The service you use should allow you to add more than one key and create a symmetric encryption key for the conversion. Your private key identifies your device, the service should know that you own multiple devices.
How would I get my ssh keys to the remote server from a new machine?
To me, the easiest way seems to be either sharing private keys from a different machine, or having some way to deterministically generate keys from a password or keyphrase, and the latter seems more secure to me because I don't have to trust a middle man to do the transferring.
There is not. I worked on a code signing project, and there was this guy who I as already warned had a bit of Dunning Kruger going on, but would later discover was also a bit of an ineffectual bully as well, when he got into an argument with both me and a customer.
Not long after the first milestone of a project with lots of milestones he announced he intended to have me to generate ‘real’ keys for the project and send him the key pairs over Outlook Encryption. For a project with public safety concerns written all over it, and would later have me pick multiple Hardware Security Modules for different steps of a multi-signature chaining process.
He tried to get me into trouble for telling him, politely, that he could fuck right off. And then had to talk to everyone he tried to tattle to about why he was a dumbass and that we were at least a year (turned out to be three) before we needed “real” keys - we were actually about four months from even needing fake keys for integration testing, let alone real keys. And I was be writing up runbooks for doing that rather than doing it for people.
The thing I would soon discover about signing keys is that everyone thinks they are a magic incantation of math. They’re just math. The magic is not inside the box, the magic is the box. It’s like a clean room: It’s a room full of nothing. What makes it special is all the work you do trying to prevent something from happening to it.
I stayed on that project almost a year past where there was any code they needed me to write (except for one bad bug I would find in my code a few months later), but they still needed me to teach them behavior, to lock in that clean room mindset.
Yeah reminds me of the time a real UK bank employee insisted that I should give him an SMS onetime code, even telling me to ignore the part of the message that I should never give the code to anyone else, not even a bank employee. I verified by other means that both he and the transaction were genuine but absolutely refused to give him that code no matter how he tried to spin it, and solved the issue a different way. Whatever manager created that ad hoc process needs to get fired.
Assuming for the sake of argument this were a real service checking for matches, the chances of a hash collision with SHA256 is effectively 0.[1] I entered the limit for BIGINT (9223372036854775807), and the approximation of the probability of a hash collision after generating 9223372036854775807 items in SHA256 is zero. The exact probability would probably take eons to calculate, but it's vanishingly close to zero.
> The maximum cycle length is 2256 ≈ 1.16×10^77 iterations. If you can evaluate 10^12 hashes per second, then working your way through all possible hashes would take you about 10^65 seconds (about one quindecillion times the age of the earth). Even if you're fortunate enough find a loop in a tiny fraction of that time, you're still liable to be waiting for trillions of years.
If this is just a meme website, just... take it back down? People are dumb, they are going to fill in real keys, and you knew this before you clicked "deploy".
Very strange. I sent a test key and didn't get that response but when I sent my real key it did. How did it know the difference between the dummy key and the real key?
"256 bits AES Encryption" should really have a "Military Grade" stamp on it. Perhaps with a metal background and some rivets or whatever for emphasis.
I guess it's to be expected, but the IPv6 Ready is bogus, too
I'm confused by this one. It says it's a joke but it still submits the key to a server.
These joke pages have been around since http://ismycreditcardstolen.com/
And I even made my own version https://hasmypasswordbeenstolen.net/
The difference is that neither the original nor mine actually submits the secret to the server. I went to great lengths to avoid actually doing it, it's still a bad idea to send a password to my page but at least you can check the source and network traffic and see that it's only checked with JavaScript and a hash is checked against the HIPB password site.
This supposed joke site sends and processes the key on their backend. At least it looks like that, I have not tried with a real key.
Yea..sending it to the server makes it look sketchy. Even for my joke site[1] I make sure everything stays client side.
[1]: https://faxyourballs.com
> Guys this is just a meme website. Please do not submit your real private key and do not report phishing.
Exactly what a phishing website would say.
I would also provide an open source version that also was backdoored
The repo needs to be clean, but pre-built release binaries backdoored. It's classier this way.
Written in Rust or Go.
Cloudflare's 1.1.1.1 for families blocks this is phishing. No sense of humor I guess?
On my home PC Avast blocks it too.
The word you're looking for is "joke" not "meme", but that isn't hip enough, right?
Thank goodness, now I know my private keys have not been leaked ...
Instead of HaveIbeenPwned.com, maybe the name of this site should be HaveIbeenKeyed.com
Wait why did it say the key was unused when I submitted the first time, but now it shows the key is already taken?
It could be a bad actor pretending to be a meme actor pretending to be a bad actor
Presumably, they took it.
> Is anybody using this private key?
They are now!
Nicely done! It worked flawlessly for me the first time. Does this support bulk upload?
I got invalid captcha :(
Do not give out your private keys anywhere except where they're needed. They are meant to be private for a reason.
If this service was serious, it'd instead rely on fingerprints (sha256/sha512) and not the key itself.
Is there any case where they ever need to be shared? If you need a login, generate a new one.
Yeah, I'd strike "except where they're needed". Never share a private key.
One of the best things you can do is generate a key per device, not per person. That way if you lose your phone you just revoke that key and not the one that you use on your tablet, work laptop, home desktop, etc.
Bonus points: monkeysphere and certificate based auth are two other great solutions for making sure the ssh server you log into is not doing a MITM on initial connection (you know, the part where it asks you to manually verify the fingerprint of the server key and you likely just hit y instead).
Forwarding your ssh agent to a host that you don’t know for certain is not doing a MITM attack on you can be devastating, as is entering a password into same.
But that way you can only use each key on that one device. E.g. No starting a private conversation on your phone and then continuing it on your desktop later.
The service you use should allow you to add more than one key and create a symmetric encryption key for the conversion. Your private key identifies your device, the service should know that you own multiple devices.
Are there really people who don't do this? Copying private keys around just feels gross like copying binaries around.
How would I get my ssh keys to the remote server from a new machine? To me, the easiest way seems to be either sharing private keys from a different machine, or having some way to deterministically generate keys from a password or keyphrase, and the latter seems more secure to me because I don't have to trust a middle man to do the transferring.
My company's system admins don't know how to do that unfortunately.
No worries, I'm sure there are lots of webpages that will generate private keys for them. For free.
There is not. I worked on a code signing project, and there was this guy who I as already warned had a bit of Dunning Kruger going on, but would later discover was also a bit of an ineffectual bully as well, when he got into an argument with both me and a customer.
Not long after the first milestone of a project with lots of milestones he announced he intended to have me to generate ‘real’ keys for the project and send him the key pairs over Outlook Encryption. For a project with public safety concerns written all over it, and would later have me pick multiple Hardware Security Modules for different steps of a multi-signature chaining process.
He tried to get me into trouble for telling him, politely, that he could fuck right off. And then had to talk to everyone he tried to tattle to about why he was a dumbass and that we were at least a year (turned out to be three) before we needed “real” keys - we were actually about four months from even needing fake keys for integration testing, let alone real keys. And I was be writing up runbooks for doing that rather than doing it for people.
The thing I would soon discover about signing keys is that everyone thinks they are a magic incantation of math. They’re just math. The magic is not inside the box, the magic is the box. It’s like a clean room: It’s a room full of nothing. What makes it special is all the work you do trying to prevent something from happening to it.
I stayed on that project almost a year past where there was any code they needed me to write (except for one bad bug I would find in my code a few months later), but they still needed me to teach them behavior, to lock in that clean room mindset.
"Never unless necessary" is unhelpful for anything
Yeah reminds me of the time a real UK bank employee insisted that I should give him an SMS onetime code, even telling me to ignore the part of the message that I should never give the code to anyone else, not even a bank employee. I verified by other means that both he and the transaction were genuine but absolutely refused to give him that code no matter how he tried to spin it, and solved the issue a different way. Whatever manager created that ad hoc process needs to get fired.
Scammer: your private key is needed.
Oh, OK.
Wouldn't it being making the matter worse? You wouldn't know if it's a collision of the hash or of the keys themselves
Assuming for the sake of argument this were a real service checking for matches, the chances of a hash collision with SHA256 is effectively 0.[1] I entered the limit for BIGINT (9223372036854775807), and the approximation of the probability of a hash collision after generating 9223372036854775807 items in SHA256 is zero. The exact probability would probably take eons to calculate, but it's vanishingly close to zero.
1. https://kevingal.com/apps/collision.html
Generate and send it every possible key
> The maximum cycle length is 2256 ≈ 1.16×10^77 iterations. If you can evaluate 10^12 hashes per second, then working your way through all possible hashes would take you about 10^65 seconds (about one quindecillion times the age of the earth). Even if you're fortunate enough find a loop in a tiny fraction of that time, you're still liable to be waiting for trillions of years.
https://stackoverflow.com/a/43636715
Edit: fixed missing exponent notation
If this is just a meme website, just... take it back down? People are dumb, they are going to fill in real keys, and you knew this before you clicked "deploy".
Hahahaha, this is hilarious!
Hey, that's not the wallet inspector...
My private key came from Debian, they patched the issues reported by Valgrind and now OpenSSL is more secure than ever.
A "dumbass" counter on this site would be interesting.
It shows on the response, when you send your genuine private key.
Very strange. I sent a test key and didn't get that response but when I sent my real key it did. How did it know the difference between the dummy key and the real key?
It doesn’t, only you see that. The owner of the site just sees *****.
You only see hunter2 because I copied and pasted your stars. I just see ****.
probably checking the corresponding public key against known public keys in various places
Can confirm
w/ signed counts
He should install Wordpress! It has lots of dumbass counters.
https://wordpress.com/plugins/browse/counter
lol. You're kidding me...