There is a solution that is easier than auditing, found within the public key system. You could use the same password for every single website without any of them ever knowing what it is. You would instead associate your account with a public key and then use it to verify your identity every time you wanted to log in.
Then, the only vulnerability is your local machine. If someone hacks a website, the only password related information they can access is your public key, but you tell that to everyone anyway. They won't be able to use that to log onto any other website, even though you use the same password for all of them.
You would still probably want to use multiple public keys, and two-factor authentication (to eliminate the single-point-of-failure risk), but the technology already exists for us to be doing this. It just needs that extra layer that will make using such a system easy for grandma, and then of course for websites to start accepting public key authentication instead of password authentication.
Actually, there's a W3C WG that works (worked?) on a protocol called WebID, that uses public keys to authenticate users, and servers are not identity providers but just serving profile information.
The solution isn't intended as a measure to resist intrusion, I agree 100% with you that using PKI as a form of two factor for hardening authentication is a great idea.
It's more of a secondary measure for forensics and incident response purposes when the intrusion resistance measures fail. If your credentials can be hacked for any reason(your key AND your password are compromised, for example), when those credentials are used you have a useful audit trail of when it happened and can possibly even get some early notification. If I hack your laptop and use your valid credentials to log in to a site, even if you log in just to disable the audit logging, there will at least be one entry of that happening somewhere. If the audit collection system supports some early notification, you can potentially change your credentials or notify the service before the hacker does something bad.
One issue with just using a public key everywhere is that the most common public key authentication protocols result in some degree of non-repudiability. This is desirable for signing in to a bank but not for potentially embarrassing sites. I guess the cryptographic community might already have an answer to this, though.
Simple and effective. I hope Mozilla is working on something like this, their recent updates have included some great defaults for privacy and security; this might fit in with their browser as authentication idea and be more secure than using email as the backend.
I also gave a talk at PyCon covering the why, what, and how of Persona, if you prefer that medium: http://pyvideo.org/video/1764
(For what it's worth, the docs need another round of polish but they should get you started. If you have any questions, please feel free to email me directly.)
Persona users' keypairs are ephemeral, and their use just to provide temporary (in practice, usually, one-time) assertion from an identity provider that you have authorized with them.
Yeah, I hear you. Persona isn't public-key-utopia, but I do think it moves us to an unambiguously better place. The protocol is built so that users who want more "advanced" authentication schemes, like client-side SSL certs, can have them. Seamlessly. But everyone gets a better risk profile, even in the common case.
My biggest problem with Persona, is that I don't own an identity. My identity is provided to me by some third party. Even if I host an identity provider on my physically owned server, the identity is still not mine, as I can't own a domain (domains are leased from a registrar, not bought).
It also does not solve many problems OpenID had. For example, multiple identities ("which provider did I use here?") got even worse and migration is still completely manual (go everywhere, tell them you have new email, good luck if you already don't have the old one) and, rephrasing the OP title, "I long for the future where I can safely assume my email provider is compromised" is impossible with Persona, too. The point is, I believe, the Persona already has known design-level problems and, I guess, will eventually go away, replaced by something else.
And I don't really understand why we need such steps and finally get to the point we are the source and are in possession of our own identities, and others are just trusted third parties that are asserting our descriptions of ourselves. Standardize an secure key escrow (sync) protocol, think about UI/UX issues (present-day browsers HTTPS certificate UI is plain ugly), have some advertisement and educating articles and that's about it.
(Added after some thinking) Well, maybe I'm oversimplifying it, though, and things are harder than I believe they are... But the only problem I ever had with GPG (which I used as identity system) is key loss and temporary unavailability. And this could be really mitigated by key escrow (trading a bit of security for usability).
But that requires sites to not be bozos, to deal with a more complex cryptosystem. If we could achieve that then we could just get them to do the damn hashing right.
Here's a simpler solution: integrate password managers with modern browsers out of the box. Each site I log on to gets a hash of my password with their domain. But I need to install an extension to get this. Just make it more accessible. It doesn't matter if you use sha-1 or md5; it'll get everyone to use high-entropy passwords, and to not reuse passwords across sites. It'll be strictly better (by orders of magnitude) than the current situation.
This does not improve the situation much - if your password is weak it is still easy to recover using a dictionary attack - just compute hash(salt + hash(password + domain)) for common passwords until you find a match in your compromised password database. As long as the only secret is the users password and this password is weak, you are out of luck whatever you do.
On the other hand if your password is strong, then it is very unlikely that an attacker is able to recover it even from a plain unsalted MD5 hash. The only thing gained is protection of reused not-to-weak passwords in the case a system storing plain text passwords gets compromised.
Ah, I see your point. Whereas if people with unsecure passwords saw others logging into their accounts they might be more likely to change their habits. I stand corrected.
> But that requires sites to not be bozos, to deal with a more complex cryptosystem. If we could achieve that then we could just get them to do the damn hashing right.
Not quite.
If a site gets the damn hashing wrong, a successful attack means that your password is now open on the streets.
If a site gets asymmetric crypto wrong, a successful attack means that particular account/site is now compromised, but your pk is still completely private, because you never send it over the network in the first place, bozo site or not. (now if the client is a bozo and allows the pk to be sent across the network, then yes ..)
No: you hash the master password, locally, and use that hash as the value you provide the remote site.
Now, they should also hash the hash, so that should it be know, your account on that site and that site alone cannot be compromised. But your master password is safe.
One of the problems with a scheme such as this is sites with multiple subdomains that use the same account per user. I'm thinking of Stack Exchange and Slashdot, for example. So simply using the hostname to generate a hash won't quite work.
But either this or the PKI method would be vastly preferable to what exists today.
For myself: I've been generating unique, per-site passwords for the past decade or more, and saving those in an encrypted database. Multiple copies of that spread around to prevent loss of access in the event of any single system going down. But otherwise: secure.
My point was that if we could change every site on the internet to use public keys we wouldn't be having this conversation because they'd already be doing the hashing right with bcrypt.
Sure you can get some sites to use it, and sure you can come up with some way to secure a few savvy people. But it wouldn't elevate ambient security if you expect every site on the internet to change.
Instead my proposal would start securing 80% of the internet by fixing three codebases.
This is a good idea; but if your single computer is hack'd that is just as bad as if someone just got on your computer when you were just walking away and you were still logged in.
It makes identity and account problems just as problematic.
I actually like the auditing idea; however I think he goes a bit overboard about having GeoIP for every single login because I know many people log in from tons of different locations all the time.
Maybe a more simpler alternative would work; but it needs to be well thought out for sure.
IP checking's not necessarily going to help. If I get your passwords, I'm going to try them with every site I know about in a matter of seconds.
Public key crypto does seem to be a better solution - I've heard it proposed a number of times among security people now. And it has some nice features even when you assume that user computers are still vulnerable to attack.
• It seems to be a harder problem to hack all the users of a service than it is to hack the service itself
• If you abstract the public key stuff into the browser nothing would change in that regard. You can use different passwords packaged with your key. Personally I don't think it's worth the bother if you assume that people tend to use the same passwords but... whatever.
• You could do all the crypto on a token and use interface controllers to reduce your attack surface there.
The difficult bit, as far as I can tell at the moment, is that it requires people to know that there's a file they need to keep safe if they want to hang onto their accounts. I really think you'd need a physical token to get it down to the level that many people are capable of understanding, and then you'd better pray they don't lose it....
If we're gonna trend that way, we add complexity - and that's not going to get people to adopt.
> but if your single computer is hack'd that is just as bad as if someone just got on your computer when you were just walking away and you were still logged in.
Computer security usually starts out from the assumption that physical access to the machine == completely vulnerable, whether you were logged in or not.
You can always buy a hardware security token, which gets the key and never ever releases it away.
Hacked computer will mean, the attacker will be able to sign authorization requests (if they know the password for the token) just while they have access to your computer. Fix the security issues and you're safe again.
How, in the practical sense, does this work on other machines then? Am I supposed to carry my public key around with me everywhere, and load it on my friends mobile device just to check my email?
The dreamy eyed answer to this is that you would have your private keys on your phone and other devices would be able to ask it to verify a token. As seamlessly as possible and/or sensible.
How does a smart card help? So every device would need to be able to read a smart card? And third parties would need to be able to accept, store and present whatever is on the card?
Yes, every device would need to be able to read smart cards, and everyone would need to have smartcards. Other than the card, everything would just look like normal public key authentication; third parties would not need to store anything other than what they would store if this were done entirely in software.
Really? We pretty much do it with cell phones right now. You can take a SIM card from one phone, put it into another, and suddenly you are using your cell phone plan with a different phone. This works for billions of cell phones.
PasswordMaker works a bit like that, although in a much more lightweight way, making a hash of the site's domain name + the master password you enter each time. The downside is that it doesn't easily work everywhere due to stupid rules like "your password must/must-not contain punctuation".
Doesn't storing a hashed and salted version of a user's password accomplish the same thing as storing a user's public key? I suppose the other advantage of doing this is it's easier to do without the password leaving your machine.
edit: I should have added it's equivalent to requiring a password of a certain length.
Doesn't storing a hashed and salted version of a user's password accomplish the same thing as storing a user's public key?
No, because a public key can't be reversed into a private key. A hashed and salted version of a short-enough password can be reversed (sometimes trivially).
In both instances it depends on the length of the secret you hold. If your private key is small enough you can brute force it as well. That sounds like it's equivalent to requiring a password of a certain length.
Now that I think about it, you also need to make sure that your hashing mechanism is preimage resistant, which is an additional place to make a mistake, so public keys do have an advantage there.
I think asymmetric keys have the advantage that, you could sign some token that includes the website name, so a phishing or XSS attack would work against one website at a time. In fact, if the token was something authenticated by the server's certificate and included the destination IP, the true website might be able to reject false signed tokens that weren't done via MITM.
There are a lot of comments touting using public keys for this.
So, you have one laptop and one mobile phone. How do you set up your "password" on both? Assume you're not "technical".
Next: your car (or apartment, etc.) is robbed. You lose both devices. OR: water damage. Whatever. You're away from home with one device, and its battery dies, wifi fails, whatever.
No worries, your brother/friend/colleague lends you a device. But... you're locked out of EVERYTHING on that device. All of your accounts require your public key, and you obviously don't have that at an internet cafe, or even at your brother's house, on a computer you're comfortable is safe.
Use the same keyring on both devices. It’s just a file, copying it over shouldn’t be a problem.
Then ascii-armor that file and print it out and/or store it on a CD, keep that in a (or possibly multiple) safe location(s). You could even give your brother the key and trust him not to try to crack the passphrase.
This is a solved problem. Look at CAC/PIV smartcards. Virtually anyone with a computer is used to carrying around a credit card or ID card. Just add a PK circuit.
All of the problems I mentioned are solved for technical users, or special situations with the right equipment available (like a CAC reader... I certainly don't have one of those integrated into my mobile phone, or laptop for that matter).
That doesn't help when we need a general solution with usability that comes close to remembering a password.
a few one time keys? the way google backup codes work. I am heavy RDP user. One of the things I hate about windows is the inability to have one time burn passwords.
The first problem with myaudithooks.com is the vulnerability of the audit site, especially if this is a hosted service accepting login reports streaming from lots of different sites.
I know, the actual usernames/passwords aren't part of the audit trail.
Or... the passwords aren't. The usernames probably are, because otherwise how would this login report be linked to the right user?
So then think about what you could do with that data, if you cracked myaudithooks.com. For the users/services using it, you'd have a comprehensive list (likely with usenames) of all of the sites these users access regularly, probably mostly with the same weak/reused passwords.
Alternative: don't crack it, just ruin it. How is myaudithooks.com going to really lock down the API calls so that only mydogfriends.com can report login events to mydogfriends.com... Otherwise you could have script kiddies just throwing in lots of junk data for fun, or a malicious attempt to discredit a bank, competitor, etc. by convincing many of their users (via fake audit reports) that their accounts are cracked.
I do think the general idea is good, though -- just not centralized.
Login auditing is good. I always appreciate the extra bit of info when I SSH into a server and see "Last login: (timestamp) from (IP.host.blah)".
It's also hardly ever used.
I suspect some of the problem is that the timestamp bit would make sense to most users, but the source is more likely to be confusing for the general public. A raw IP address certainly won't be useful, and location is very scary if they don't know it's not exact and sometimes wrong ("it said last login from the next town over... where my ex lives!!!"), and that means support costs for false positives.
The usernames do not need to be part of the audit trail -- the unique URL identifies the site it came from. You know you your own logins, presumably, so it doesn't need to be there.
myaudithooks.com should not be centralized -- I 100% agree. You should just be able to put any old URL there. If I want my audit entries to go to my box, I absolutely should be able to.
You're right, some attacker could post bogus information if the know the url... however, the urls should be unique enough that they can't just be randomly "guessed" by an attacker. Another alternative is to provide a callback url, the way stripe does, so the service can "authenticate" the audit log entry before I consider it valid. For example, if I receive an audit log entry with id "abcd1234", I can hit http://mydogfriends.com/audit/abcd1234 to make sure it responds appropriately.
The idea isn't fully fleshed out yet, but I think it wouldn't take a lot of work to make it happen.
The really tricky bit is always figuring out how to apply the idea to the general public.
Where would all the users who find websites by typing domain names into Google ask mydogfriends.com to send their audit entries?
People running websites are also not necessarily technical -- often there was a techie involved during set up, but then it's just "apply the wordpress updates when it prompts you" and that's that. Support for audit trails needs to be built-in by default if it'll be widespread.
Interesting stuff, anyway. It's worthwhile to keep fleshing out the ideas and possible pathways.
Unfortunately, passwords are to account security what PHP is to web development. It may not be the best, it's not the fastest, it even may not be the most secure. But it's ubiquitous, it's free and if done right, it's an OK way to get the job done precluding more complex solutions that aren't as practical for most of us.
I think I posted this elsewhere or maybe here, but I got around the password remembering problem by keeping one master file of all passwords/usernames/emails etc... that I keep GPG encrypted ( specifically http://www.gpg4win.org/about.html ).
All passwords in the master file are randomly generated. That is, of course, the account I'm creating is a throwaway at Paul's Peanut Brittle shop. Interestingly, paulspeanutbrittle.com isn't taken.
Wouldn't an attacker who's gained enough access to a system to get db dumps or modify serverside code to the point where they can capture incoming passwords simply turn off the audit calls?
Wouldn't an attacker who's gained access to a secondary account through a password derived from a db dump change the audit URL?
Beside that, knowing an account is compromised is better than nothing but often not particularly useful - see all the horror stories by people who've had their gmail account compromised. They tend to find out very quickly the account has been taken over, recovery is still difficult and the loss of data/time/neurons is often significant.
A user isnt only vulnerable when the db gets hacked. People have other ways at getting at passwords (sometimes they guess). The idea is that if you see a lot of incorrect password attempts, you also know that something funny is up. Or, you could also see that a login attempt was issued from a computer in Nigeria (even with correct credentials). Imagine if you got a popup on your phone whenever you logged into your bank account. Wouldnt you feel a lot more safe that no one else has your information?
The scenario presented starts with a stolen db. Also it's about recording successful, rather than unsuccessful logins.
Gmail is a good counter-example - it does tell you of your last login but who keeps track of these? You log in from home, from work, from your iPhone, from your friend's wifi, etc.
And you needn't stop there. What if the auditing service is compromised? What if the convenience-inclined user is using the same password at myfancyaudit.com as they are at mydogfriends.com and at their bank? Maybe I'm missing something but it mostly seems like a way of shuffling trust around without significantly improving security.
Its not shuffling around security and neither is it adding any (at least in the crypto sense). Rather, it is a post-mortem way of knowing whether something is wrong. Assume that neither the auditing agency is cracked nor the original service. If your password gets phished and the attacker logs in as you, you will get a notification about it. Then, you can at least do something retroactively (even seconds later if you get a notification on your phone) to prevent further injury instead of finding out weeks later when all the damage is already done.
> If I owned myaudithooks.com, I could have it email me based on certain rules. (...) I’d be able to sleep a little easier knowing that if one of my account credentials were compromised — whether it be due to my own carelessness or that of a random developer’s — I’d have a nice history and potentially even alerting so I know about it when it happens.
Humans are notoriously bad at choosing passwords, so what about this approach:
When you register for an account you write down on a piece of paper 4 words chosen at random by a computer (eg. "regain gauge chest Texas"). Then to log you provide (a) your email address, (b) your password, and (c) the passphrase printed on the paper.
This is bit of a pain for the user, but it would greatly strengthen the security of the website because it would not depend on the security of any other websites. For a to-do-list website I can see it's not worth it, but I cannot understand how some financial websites still think it is acceptable to use only email+password authentication. (I'm looking at you, Mint.com and Schwab.com).
PS: I just tried registering for a Mint.com account - it didn't let me use "password" as my password, but when I used "password1" it said, "You have a Good password". Wow.
That's just a bigger password that they're instructed to keep a copy of then? If you're going to do that, just add a proper OTP factor like a SecurID token that they can carry with them.
Yes a SecurID token is probably more secure than a piece of paper, but it is also less convenient and more expensive.
Also, the piece of paper with 4 words will have 52 bits of entropy while a SecurID token with 6 digits has only has 20 bits of entropy. So I wonder whether SecurID would be easier for an attacker who has access to the password hash and salt to derive the original password...?
In any case, whether you use a piece of paper or SecurID the main point is that financial sites which only require email+password are being negligent in their duty to protect user data from unauthorised access.
This sounds like a good idea. I think it gets one thing wrong: Hacking living social was not about gaining access to anyone's living social account. It was about getting passwords that were reused on sites that actually matter (banking, etc).
A notification that someone has logged into your livingsocial|facebook|twitter|linkedin is only valuable if it compels you to immediately change all of your other passwords. Which might be a decent idea for a version 2 of this hypothetical software...automatically change all of my passwords whenever one of my accounts is compromised.
The sad thing is that people reuse their passwords so often. Just remembering two passwords, one for important stuff and one for social stuff, would go a long way toward making this a non-problem and taking a security burden off of a lot of startups.
Why are we not already using the equivalent of an RSA token for authentication on the web? Of course, the physical token is replaced with a software app on your computer or mobile device. Is there something about the physical device that cannot be replicated in software?
If some malware gets to your phone or computer, sniffs the password and steals the keyfile it's over. There're no other options but to immediately revoke the key. Hardware security tokens are specifically meant to mitigate this issue.
Otherwise, there're many software implementations out there. Your browser should already have one (search for HTTPS client certificate authentication), although it's not universal due to some X.509 PKI architecture constraints.
1. This is an excellent idea, for the reasons stated. Auditing is a huge part of enterprise best practice; it should be best practice for consumers as well, and enterprises should help them with it.
2. That said, the number of sites for which we need really solid security is probably under 10. For me it's primary email, 3 for websites I own/hosting/etc., Paypal, bank, arguably Amazon, and not much else. And frankly I forget my bank password and have to keep resetting it (which is part of why my email needs to be secure).
I tried using various Single Sign On solutions but somehow their system are not satisfactory. I recently heard about this new company called SmartSignin - https://www.smartsignin.com and their website says that their patented technology doesn't store your password anywhere so it's impossible to hack it. I don't know how they do it but I'm intrigued. Does anybody else know anything about them?
You might take a look here [1], using asymmetric crypto. We are still developing it but that is our approach. Yes, there is some overhead but you will need it anyway.
The doc is a bit outdated but the prototypes work.
First, it's awesome that this rather important subject is getting attention, and kudos to Jen for giving it thought and providing a perspective [1].
Logging adds value once an account is compromised, so is a contingency measure (minimising impact). Solving this problem requires mitigation (minimising probability) as well as contingency.
Many comments here suggest the use of PKI. PKI is part of a solution and, as with logging and audits, requires more.
PKI's biggest problem is that it doesn't scale. The question then becomes one of issuance. Self-issued certificates have no credibility so cannot be trusted. That problem is solved by using a certificate authority that can be trusted.
That leads to the next question, which is whom to appoint as a certificate authority (CA)? This thing [2] should scale, so my certificate must work world-wide, with any web site and, while we're at it, offline in meat space.
That makes canidates like my bank or a credit check agency bad choices, because they haven't the reach. Credit card companies like Visa, AMEX or Mastercard have better reach, but that only accounts for a tiny percentage of the world's population, because it excludes the poor.
The only viable choice then becomes the organisation that already deals in identity - government departments that issue passports, ID cards and driving licences.
Of course that's just national. The solution to that problem is to federate identities between governments. Awesome. First part of the problem solved [3].
The next part of the problem is anonymity, and it's various variations. This can be solved by using a privacy-enhancing credential - a problem that was solved by Stefan Brands at Credentica [4].
The tradgedy is that while these solutions exist, are mature and proven, there is just not enough incentive to make them a reality.
Some closing notes: Any good identity system must adhere to all the laws of identity (http://www.identityblog.com/?p=352/#lawsofiden_topic3). Technologies like OpenId, Persona and OAuth don't even come close. SAML and WS-Federation do a much better job of it, but both SOAP/XML-based. Which makes them unpalatable to many. There's an oppotunity in there somewhere...
[1] Logging has been done - just not at the scale Jens envisions. Many military and intelligence systems inform the user of previous acvitivy on login. The better ones use geolocation to tell the user where the most recent logins occured.
[2] "This thing" is really an identity meta system.
[3] This technology exists in the form of WS-Federation and, to a lesser extent, SAML (which relies on the browser, so doesn't work at the service level).
[4] Stefan Brands came up with U-Prove, which was open-sourced by Microsoft after they aquired the technology. IBM have also come up with a privacy-enhancing technology (PET) called idemix (identity mixer). An important attribute of any self-respecting PET is that it must be claims-based, so that it functions in a world of federated identities.
Isn't the issue with PKI the 'I', rather than the PK?
In the case of replacing passwords at a website, the issue of 'credibility' or 'trust' is irrelevant - you have no trust or credibility with a u/p, so why do you need that with a PK?
If I'm just replacing user/pass with a PK, why do I need a CA and all the infrastructure around that? The goal is to put something serverside that cannot be used against me elsewhere - a 'public' token that lets us communicate in secret.
The only concern is one of tampering, which would be a problem in either direction anyway.
Mostly because you need the "I". Unless you start accumulating PKs as we do passwords. Some sites will require access revocation, others not. Some require known identities, others not. Unless an identity system is ubiquitous it won't gain widespread adotpion. For it to be adopted it needs to address every scenario that an identity meta system faces.
Why can't I just use the same PK everywhere? The whole point is it's not reversible to the Private key.
Nothing else about how passwords are handled would have to change.
Public key auth works pretty okay for ssh with a single keypair. I don't see why it wouldn't work for websites too. (As count also mentions) the entire point is that you can prove your identity without giving the entity you're proving to the ability to do the same.
The only viable choice then becomes the organisation that already deals in identity - government departments that issue passports, ID cards and driving licences.
What could possibly go wrong? There's a reason why it's unconstitutional in my country for the state to issue a single ID number to every citizen.
A protocol should let anyone be a CA, and it should be up to each party to choose what CAs it accepts. If some service wants to only allow government-issued IDs, that's fine, but there's no good reason to enforce that at the system level.
In fact, the article you linked puts it well:
But in many cultures, employers and employees would not feel comfortable using government identifiers to log in at work. A government identifier might be used to convey taxation information; it might even be required when a person is first offered employment. But the context of employment is sufficiently autonomous that it warrants its own identity, free from daily observation via a government-run technology. (...) So when it comes to digital identity, it is not only a matter of having identity providers run by different parties (including individuals themselves), but of having identity systems that offer different (and potentially contradictory) features.
Technology like U-Prove addresses exactly that scenario. Using it you could prove to a third party, using a government-issued credential, that you're over 18. You wouldn't disclose anything else. The third party couldn't derive you gov. Id, and the government couldn't prove whom you provided your credential to - even if the two collude.
"Self-issued certificates have no credibility so cannot be trusted"
How is that? I see the process working like this:
* I sign up for an email account by sending a request with a username and a public key. No need to "trust" the key, because this is an identity creation process.
* My bank issues a smartcard when I create my account, which can be used to log in to their website.
Sure, there are problems -- key revocation and dealing with lost secret keys are probably the biggest. Those problems are shared by passwords. The point is to solve the more glaring problems we have with passwords, like the fact that you need to rely on many different websites to manage passwords securely, or the fact that humans are terrible at picking passwords.
"The tradgedy is that while these solutions exist, are mature and proven, there is just not enough incentive to make them a reality."
Bingo. That's the real issue, and it always has been.
Then, the only vulnerability is your local machine. If someone hacks a website, the only password related information they can access is your public key, but you tell that to everyone anyway. They won't be able to use that to log onto any other website, even though you use the same password for all of them.
You would still probably want to use multiple public keys, and two-factor authentication (to eliminate the single-point-of-failure risk), but the technology already exists for us to be doing this. It just needs that extra layer that will make using such a system easy for grandma, and then of course for websites to start accepting public key authentication instead of password authentication.
edit: http://en.wikipedia.org/wiki/Public-key_cryptography