101–110 of 254 posts
Hi, can someone explain me why SSL client authentication is not widely used? You can use the same protocol you use to authenticate hosts to authenticate users, yet no one seem to do that nowadays. I'm not professional web developer so maybe answer to this question is obvious (but I just don't know it).
Hi, can someone explain me why SSL client authentication is not widely used? You can use the same protocol you use to authenticate hosts to authenticate users, yet no one seem to do that nowadays. I'm not professional web developer so maybe answer to this question is obvious (but I just don't know it).
I have worked with systems that use it to authenticate machine to machine communication (e.g. a web backend authenticating itself to another service doing work for it). In that environment it works well. Using it to authenticate a person regardless of device doesn't work so well from a usability point of view.
Earlier quoted context omitted.
For public services, getting users to have keys and install them in their browsers is quite hard. For APIs, it should be more manageable but many places stumble with key management and a lot of developers were resistant to learning enough about the tooling to do things like manage test instances.
I guess regarding the public services your statement may be correct. But I wonder if anyone (any significant content provider) actually tried. The technology is available for > 10 years at least (including browsers support). I think it's an issue for most people that they need to manage multiple passwords and it sometimes turns off people from actually using the service. With client certificates you install certifica…
The problem is that this isn't really true: it's more like this:
1. You go through a tedious and convoluted process to get the certificate, which requires using a largely-ignored browser feature which is now deprecated: (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...). Even when it was implemented, the UI is not great – e.g. https://www.instantssl.com will fail if you fill out the form too quickly before the browser has finished generating a key.
2. Wait for the email to arrive and follow the retrieval process to get the certificate. Then follow the clunky UI to install it. You'll be told that it's really important to back it up but e.g. Firefox won't give you any instructions about where to even start to do that.
3. You then need a non-trivial amount of work to export the private key and certificate and install it on all of your devices, which is another process where the UX was apparently never considered seriously at any point over the last 20 years.
5. Every time you visit a site or send an email, you now have to select which key you want to use.
6. Every year, repeat the process starting at step 1.
Don't get me wrong, I'd love for this to be available and am still somewhat amazed that after however many years nobody has made a serious effort to improve the experience. It'd be really nice to have a LetsEncrypt-style effort to remove the warts from this process so it's approachable for normal people without a heavy support pool.
This is another area where I wish Mozilla hadn't prematurely killed Persona as it'd be really nice if there was a service which would allow you to associate different client certificates with a single user identity so private keys never needed to leave the device, and register things like tokens. A U2F-style focus on the user-experience would be really nice: once a year when you try to login it redirects you to a page which says “Enter your password and tap the token if you want to keep using it" and refreshes the certificate with no other ceremony.
Earlier quoted context omitted.
Doesn't a session token violate the stateless principle ?
Yes, if you mean a token that identifies a session that is saved on the server somehow. But not a JWT, which is only saved on the client and verified on the server.
JWT is also poorly specified (no protocol under any circumstances should use negotiation, it does not support revocation, and it has been hammered home by the best security folks I know that public key cryptography is what you do when you don't have any other choice) and dangerous to use. Avoid it. Do the simplest thing that can possibly work. That's a session token. If, in the far and unlikely future, you are so successful that a single database call is so harmful, then you have the money to hire someone who doesn't have to Ask HN this question.
Earlier quoted context omitted.
How do you share your blacklist across servers
The same way you share any of your other data across servers. Save it in a DB or Redis instance that all your servers can reach.
Do the simplest thing that will work.
Earlier quoted context omitted.
Seems to me the answer is indeed that simple: use OAuth2 and be done.
OAuth 2.0 is so bloated that it scares people off. Something like the client credentials flow is relatively easy to implement on your own and is basically lets clients exchange a client_id (username) and secret (password) for an API key. Bonus: If you stay close enough to the standard you can plugin a real OAuth 2.0 provider if/when you decide you need it.
I think we're thinking the same thought, maybe my terminology is sloppy.
Suppose we just say "Use this token-generation endpoint (with your credentials) to generate a session token, and attach that token by means of OAuth 2.0 Bearer Token in subsequent requests to other endpoints".
Doing that, we can easily scythe off any bloat, no? We don't care about people signing-in with their Google accounts, or anything like that. Or is that what 'client credentials flow' means?
Do everything via HTTPS, disable HTTP. The login request (POST, dont use url query params) contains username + password. The API replies with a session token (a random string). You can store any metadata relating to this session token in your DB. The API client should this token in every request that requires authentication, often in the header as `Authorization : Bearer 123TheToken456`. JWT: If DB performance become…
Is this "go code this yourself" advice, or just what to look for from pre-existing tools? In my world there are middlewares that accomplish exactly this, it never occurred to me to code this myself, lest I screw it up.
If you don't mind running a PHP application, or it being built in Laravel, (I don't, but some do) it's actually a really good implementation of a solid OAuth package[2] (Disclaimer: I am a maintainer on oauth2-server).
You can set this up in a couple of days, and it'll be ready to roll for the majority of use-cases. With a few simple tweaks and additions, you can have it doing extra stuff pretty easily.
In one build I'm working on, this acts as just the authentication layer. The actual API that relies on the tokens this generates sits elsewhere and could be written in any other language (it's not in this case).
[1]: https://github.com/laravel/passport [2]: https://github.com/thephpleague/oauth2-server
Earlier quoted context omitted.
Can't store password on device (it's a device we don't control) Can you expand on this? Because storing a device-specific password (or api key, which is essentially the same) would be my first suggestion. If it's because you can't configure the device, then my suggestion would be to create a process that embeds the device key into the software before deploying to each particular device.
We need to run software on clients machines, we need this software to be running as service (no UI). This service needs to communicate back to use securely via our Web API. We could have a password entered by our systems guys who deploy to a new machine for the first time, the service encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. I'm not sure if that would be a g…
This technique is referred to as "Mutual Authentication": http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLS...
Basically, it's 2-way SSL. You use signed SSL certs to authenticate the server to the client and the client to the server. You could use your own cert signing server or employ a third party cert signing service.
Using this method, your techs would need to set up the SSL cert for the client machine when installing the software, or, the SSL setup procedure could be part of the software installation procedure.
Interesting idea that may solve your problem. Hope this helps.
Earlier quoted context omitted.
Doesn't a session token violate the stateless principle ?
Yes, it does. If you want to be completely stateless, you need to send the authorization info on each request, probably as basic auth headers. This is actually simpler than implementing the Bearer token, for both client and server, but requires that the client retain the non-expiring username and password, rather than retaining the expiring, session-specific Bearer token.
IMO, this makes this simpler solution a non-starter. It becomes way too easy to leak credentials.