I want to authenticate a client of a webpage and make sure it is a particular user.
Let say that we already agreed on a particular hash (SHA256, actually, which I think is secure enough for this) and we both already exchanged a key in a file through a trusted medium.
This key is pretty much a t...
Unless you're planning on repeating this for every http request, the session will be vulnerable to hijacking. How do you propose to deploy the key to the client?
No cryptography using client-side JavaScript can be secure without HTTPS. Any MITM attacker can send JavaScript that can do anything with the secrets the browser has access to, then there will be no secret.
@almosnow You said "3. The client has access to an input field where they load their key file." All an attacker have to do is to change the script and upload the file to the attacker's server.
@almosnow - I'm curious, why can't you deploy HTTPS? It sounds like you are trying to implement a network connection that maintains both integrity and authenticity, two things that SSL is really good at and that are really hard to implement without SSL.
@NeilSmithline Sure thing, some guys need to send data to my HQ, the information they send is not sensitive per se so I don't care if it goes in cleartext what I do care is to be absolutely certain that they are the ones providing the information on the other side (as well as which one of them is it). I know already that security experts love to repeat buzzwords here and there because they read it everywhere in magazines and blogsm but when these guys enter the real world (which may never happen, btw) they'll find out that it's not necessarily made of all the things they assume to be true.
Cont. well, since I'm deploying this to my clients here and there (most of them people who barely know how to turn on the computer and send me their data) I need to think of the easiest way to achieve this, from an user perspective. HTTP through port 80 over TCP/IP is the most widely deployed medium to exchange information that ever existed, so I'm going to take advantage of that. And yeah that's it. If you think of a better alternative for solving the overall problem, please let me know.
Web browsers support HTTPS, and providing a password to the clients would give exactly the same level of confidence that it is them on the other end. You are overcomplicating this, whilst ignoring simple, well tested, options.
@almosnow: "security experts love to repeat buzzwords here and there because they read it everywhere in magazines and blogs" - TLS/SSL/HTTPS are very well deployed in the real world, and are very much solving real problems. Every major HTTP server can handle HTTPS, and you can even get real server certificates for them now for free courtesy LetsEncrypt. Hell, you can even deploy HTTPS over port 80 if you absolutely have to for firewall or other reasons (example.com:80).
If you need to verify that the data was sent by the sender, but you don't care about the confidentiality of the data, and you're limited to plain HTTP, would it suit your purposes to have the sender sign the payload with GPG (or similar) before sending?
Secure is like "North" or "pretty" "Is this secure" is like "Is this city North?" or "Is this person pretty" - the term has no meaning without a standard of evaluation. You can safely say that Adelaide is unlikely to be North, (unless you're coming from Antarctica), but if you ask an inhabitant of Brazil and an inhabitant of Iceland whether Mexico city is "North", you're going to get different answers.
Discussion on question by almosnow: I…
Discussion on question by almosnow: I…