One of the goals of OpenID is to be resistant against the failure of any one corporation. This sounds good, but there is another problem: if the site your ID is hosted on goes down, so does your ID. I thought that there must be a login system that would be totally resistant to failure.
My idea is like this: I go to a website and I have to login. I give them my public key. The website sends me back some random data. I sign this data with my private key and send it back to them. If the signature is valid, I get logged in. This has the advantage that my ID is just my public key, so I don't rely on any external site.
To make it so that users don't have to remember there keys, the system could also optionally allow an OpenID-like system where my keys are hosted on some server and the original site redirects me there to login, and that site signs the data and sends it back to the original site, and I am logged in. This method would work similar to OpenID, but would allow me to back up my keys so if that site goes down, I can use another site.
Is this a practical system? Am I just wasting my time? Should I not reinvent the wheel and just use OpenID?
Identity cards, like Windows Cardspace, are a good alternative because they are stored on your computer and can be backed up. This is technically called the Identity Metasystem or Identity Cards.
This is different from a centralized identity service like OpenID. The good thing about the OpenID system is that the chance of everyone's identity server of going down is pretty small. However, individually, each user can possibly experience an outage.
The InfoCard system by Microsoft is a good solution, although it has not been very popular.
This is not a new problem-- email signing and encryption is a similar solution to private/public key system. GPG actually does have keystores where you can post your public keys so that people can verify your signatures.
If you're really wanting to avoid any possibility of an identity server being down(a pretty strict requirement), use CardSpace, or some other private/public key system where the users themselves have the keys, and only have to demonstrate that they have them by some challenge-response hashing algorithm.
Also, the cardspace solution is not strictly a Microsoft thing, there are plenty of applications for all operating systems. I believe it is a public standard.
This is very similar to how HTTPS works.
With your idea, you need to take good care of your private key. What if your comnputer crashes, etc. Also what about logging in from someone eleses computer? Would you trust putting a thumb drive with your private key on it into someone elses computer?
This is also very similar to what the military does with ID cards with private keys embeded on a chip that they issue to service members. A member needs to put his ID into a special reader as well as logon with a unique ID and password that must be changed periodically. This is to take care of the case where a member looses his ID and someone else trys to use it.
So I guess my answer is yes, you have a good idea, but perhaps you just need to refine it some more.
Use OpenID. It's so easy to set up and you don't have to debug it.
Windows CardSpace supports something like this. But it hasn't really taken off.
The problem with your system is that if you lose your key due to hardware problems or a system crash, you lose your only way to get to the sites you use that key for.
I would say OpenID is sufficient.
I see a couple issues with your system
I need to have that key to login. If I go out, and don't have the file on my person or hosted remotely, I'm out of luck. I also may not be able to enter it on my cell phone or some other device.
You will also need to protect the key from loss. Which likely means password protecting the key, which takes away alot of the convenience of the system.
What needs to happen for OpenID to be more resistant to ID provider failure, is for sites to allow multiple OpenIDs to be associated with an account, just like SO does. So, your idea may end being workable, but I think the effort to get it working and adopted would be much greater than the work to get widespread adoption of sites allowing multiple OpenIDs.
Also, check this link for a description of TLS Client Authentication
Related
I wonder if I might ask for opinions on a simple authentication system I'm thinking about for a pet web site project where the overriding requirement is that the system should have no way to tell who the user is, i.e. have no way of identifying or contacting them.
The system does need to distinguish between these anonymous users of course, and prevent users pretending to be other users.
Perhaps in a strict sense it's not an authentication system at all, more like a distinguishing system.
A simple solution would be to assign a Guid to new users, which gets stored in a cookie/local storage/whatever and used to distinguish them.
Then give the user the facility to copy the Guid, and/or generate a URL that they can bookmark or otherwise store locally, which re-supplies the Guid to the site and stores it as a cookie again - to be used if the cookie is deleted or they want to authenticate from another machine - by using the generated URL or pasting the copied Guid into a 'login' page on the site.
This means there can be no 'I forgot my password' facility; if the user loses their credentials, they are forever lost, that's accepted.
Additionally, if the credentials are stolen, or the user's cookies are compromised, then the credential is stolen forever, there is no way for the real user to lock out the thief, that's also accepted.
Clearly the user would need to make damn sure they store this URL/Guid somewhere safe, that's accepted.
As an aside, there could be a feature that allows the user to regenerate the Guid, which might be used if they accidentally broadcast their Guid somehow, but that also means if somebody steals their Guid and uses the regenerate feature before the 'real' user realises, the real user will be locked out forever - maybe best it's unchangeable so at least if the Guid is compromised, the thief cannot lock out the real user - but this is an aside.
Given the requirement for complete anonymity / non-contactability, and accepting that losing the Guid is like losing a dollar bill, you lose it forever, it seems a reasonable and pleasantly simple solution.
This is essentially the same as having a user/password combination with no email address or other contact details, but more secure than user: sally123, password: mydogsname1968 or whatever just by virtue of it being a Guid, not something the user can remember or easily scribble on a post-it note and stick to a monitor.
It also has the advantage that a user who uses the same machine all the time (and doesn't delete cookies) never has to login or think about credentials at all.
The Guid could actually be two Guids stuck together or three of them interleaved byte by byte, whatever - a unique auto-generated chunk of data that reflects how unnecessarily paranoid the developer is feeling.
Can anyone tell me why this wouldn't be a good solution, given the anonymity/non-contactability requirements and the drawbacks accepted above, or perhaps suggest a better solution.
If it makes any difference to anything, it'll be a Net Core 5 / Blazor Web Assembly / MongoDb application, it's a pet project so doesn't have to pass muster with any client requirements or existing systems etc.
Thanks for any advice/help.
Assuming you have registered your device with Google 2-step Verification, what information does it use to verify that you are on that device when you come back to the website?
Does it store something on your computer (like a cookie), or does it use some other algorithm to determine where you are logging in from?
It stores various bits of information about your conversation with the server. SSL cookies, session data such as your IP address and other information about your browser. As you change this information, a risk assessment value is increased as deviation from the originally known values changes. Once this value reaches a certain threshold, based on your country's online risk profile, that sets off a chain of events that invalidates your session.
When your session is invalidated, you need to log-in again.
It's more complicated than a cookie, but it involves cookies too.
There is a lot of debate in the security community as to whether it matters to add protection beyond endpoint and cookie verification and when it becomes a nuisance to the end user.
Just a quick follow-up on this question. A lot of people continue to view this question, but surprisingly, there hasn't been a good answer posted.
Since the original post, I did a lot of research to find out what technologies are used to determine a unique device, and I finally stumbled across the panopticlick project.
This website answered a lot of questions because it showed the exact metrics that a website can use to fingerprint your browser. Using this methodology, a site can really narrow down the exact device that you use to connect to a service, and therefore make it much easier to validate a 2-step verification.
Hopefully this helps someone trying to implement 2-step on your site.
I'm trying to set up a server that will be logged into by people paying for a service I offer, but I want to make sure that only those people who I want can access it. I obviously can't simply give each one a different user account because they could simply share credentials with other people. Is it possible to restrict SSH access by MAC address or RSA Key or something like that? By IP doesn't work either because multiple people can sit behind a single router.
Yes, you could use a RSA key, using RSA's PAM modules. http://www.rsa.com/node.aspx?id=1177
No, there's no real effective way to tell programmatically who's sitting at the keyboard (which is effectively what you're after). Without more details on what the service is, it's hard for me to offer exact suggestions, but one good bet might be to design the service such that it's less useful on a shared account.
i am starting to use cryptostream class. i may be wrong, if you encrypt something, close the app, and then try to decrypt it, it will not be able to because a different key will be generated. because i do need this functionality, i am wondering if it's possible to save the key in application settings and whether this is the right way to go?
If you always run your app under the same user account (it can be a local user or a domain user), the best option would be to use DPAPI. The advantage of using DPAPI is that you do not have to worry about the key (the system generates it for you). If you run the app under different user identities, then it gets more complex because the options that are available range from bad to worse (the major problem is: how do you protect your secret: key, password, passphrase, etc). Depending on what you want to do, you may not need to use encryption at all (e.g. if you want to encrypt a connection string, consider using integrated windows authentication, which does not require a password). For more info on the topic, check out this MSDN article: Safeguard Database Connection Strings and Other Sensitive Settings in Your Code; it may give you some ideas.
Lots of applications save the keys in configuration files. It's a common bad practice.
It's not secure but all secure options are hard to implement. There are options using different factors,
You can derive the key from a password using PBE (password-based encryption). But you have to enter a password to start your application. This is so called "What you know" factor.
Put the key in a smartcard. This is very secure but you need to have access to the card on the machine. This is called "What you have".
Ignore other schemes involving encrypting keys with yet another key. It doesn't really change the security strength.
Right now I'm building a personal site/blog and have pretty much got it they way I want except I'm in two minds about how to add posts to it.
It's just me who'll be adding posts and to me having a user / name password to log in seems rather passé ;).
I'm looking in to alternatives to play around and experiment with and one idea I have is this:
Generate an asymmetric key, I personally keep the private and the site has the public key. When I try to add a post or modify any content the site will generate a random string, encrypt it with the public key and display it. I decrypt this using a little app I could whip together and pass the unencrypted string back to the site which will allow the modification to continue.
I'm just wondering about any caveats I should be on the look out for, or if anyone thinks this is a bad idea, perhaps an alternative I could try?
Why not just have a user name and password and either have your web browser remember the login, or send an authentication cookie back that doesn't expire. Use a self signed SSL cert to secure the communications channel. If you want to use public/private key crypto just setup an SSH tunnel and post from localhost on your server. Trust me, it's better to re-use known good crypto/security than to try to roll your own.
Why not go one stage further from your suggestion and put the encrypted string in to the URL?
For example, turn the current date and time into a string - eg. 0904240905 - encrypt it with your private key and add this to a URL, e.g. http://yoursite.com/admin/dksjfh4d392s where dksjfh4d392s is the encrypted string. You site then has a servlet which extracts the encrypted string from the URL, verifies that it decrypts to a recent time and then gives you a session cookie while allows you to perform admin tasks.
I think the asymmetric key is an elegant solution - but a username/password is almost certainly going to be easier to implement.
If you're building your own site then you are just doing it for kicks (otherwise you'd be using WordPress, Drupal, Django, etc.) so why not do things differently?
You might find that having to carry around your keymat app might get a little restrictive, if you find yourself wanting to blog but without the means to identify yourself.
But, that said, #Kurt has the right idea for crypto - DIY is almost certainly going to be worse than using something already tried and tested.
One of the wisest statements I ever heard about security was "don't try and re-invent it".
Online security has been through so many iterations that it's highly likely that any bright idea you come up with has some flaw that has previously been found, considered and fixed.
If you want "casual" security, secure your site with a user name and password. If you want "strong" security, stick an SSL certificate on top of it. If you want "bank" security, add in anti-keystroke security.
SSL client certificates do this anyway. Why not just use one of those?
The main reason more people don't use SSL client certificates is that they're an administrative nightmare - you have to get end-users to create keys, then sign their certificates, then make sure the end-users don't lose their keys (when they lose their laptop, upgrade to a new OS etc), which they usually do, so you have to sign YET MORE certificates when the end-users lose their private keys.