How to secure passwords over HTTP?
up vote
24
down vote
favorite
Say my password is abc
. I want to send it to the server over HTTP.
I could send it in plaintext and let the server hash it and compare it to the entries in its database, but then anyone that can see traffic over that connection would see the password in plain text.
So then I could hash it client-side and let the server just compare it without hashing since it's already hashed (or the server could even double hash, but no difference in this situation). But then again anyone that can see the traffic would see the password hashed, and then send the hashed password to the server and the server would accept it.
How do I send passwords over HTTP? Do I need to implement some encryption algorithm like RSA public key encryption? Or is this impossible?
The method should be usable in any browser.
encryption passwords web-application hash http
New contributor
|
show 7 more comments
up vote
24
down vote
favorite
Say my password is abc
. I want to send it to the server over HTTP.
I could send it in plaintext and let the server hash it and compare it to the entries in its database, but then anyone that can see traffic over that connection would see the password in plain text.
So then I could hash it client-side and let the server just compare it without hashing since it's already hashed (or the server could even double hash, but no difference in this situation). But then again anyone that can see the traffic would see the password hashed, and then send the hashed password to the server and the server would accept it.
How do I send passwords over HTTP? Do I need to implement some encryption algorithm like RSA public key encryption? Or is this impossible?
The method should be usable in any browser.
encryption passwords web-application hash http
New contributor
83
Why can't you just use TLS? There's really no other way to do it securely.
– AndrolGenhald
Nov 9 at 13:58
4
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer
– FireCubez
Nov 9 at 13:59
1
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical.
– Solomonoff's Secret
Nov 9 at 17:54
3
Is this a real problem you are facing or just a thought expirement?
– whatsisname
2 days ago
1
@whatsisname I stated that in a previous comment, it's just an experiment
– FireCubez
2 days ago
|
show 7 more comments
up vote
24
down vote
favorite
up vote
24
down vote
favorite
Say my password is abc
. I want to send it to the server over HTTP.
I could send it in plaintext and let the server hash it and compare it to the entries in its database, but then anyone that can see traffic over that connection would see the password in plain text.
So then I could hash it client-side and let the server just compare it without hashing since it's already hashed (or the server could even double hash, but no difference in this situation). But then again anyone that can see the traffic would see the password hashed, and then send the hashed password to the server and the server would accept it.
How do I send passwords over HTTP? Do I need to implement some encryption algorithm like RSA public key encryption? Or is this impossible?
The method should be usable in any browser.
encryption passwords web-application hash http
New contributor
Say my password is abc
. I want to send it to the server over HTTP.
I could send it in plaintext and let the server hash it and compare it to the entries in its database, but then anyone that can see traffic over that connection would see the password in plain text.
So then I could hash it client-side and let the server just compare it without hashing since it's already hashed (or the server could even double hash, but no difference in this situation). But then again anyone that can see the traffic would see the password hashed, and then send the hashed password to the server and the server would accept it.
How do I send passwords over HTTP? Do I need to implement some encryption algorithm like RSA public key encryption? Or is this impossible?
The method should be usable in any browser.
encryption passwords web-application hash http
encryption passwords web-application hash http
New contributor
New contributor
edited 7 hours ago
Anders
47.1k21132155
47.1k21132155
New contributor
asked Nov 9 at 13:57
FireCubez
23525
23525
New contributor
New contributor
83
Why can't you just use TLS? There's really no other way to do it securely.
– AndrolGenhald
Nov 9 at 13:58
4
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer
– FireCubez
Nov 9 at 13:59
1
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical.
– Solomonoff's Secret
Nov 9 at 17:54
3
Is this a real problem you are facing or just a thought expirement?
– whatsisname
2 days ago
1
@whatsisname I stated that in a previous comment, it's just an experiment
– FireCubez
2 days ago
|
show 7 more comments
83
Why can't you just use TLS? There's really no other way to do it securely.
– AndrolGenhald
Nov 9 at 13:58
4
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer
– FireCubez
Nov 9 at 13:59
1
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical.
– Solomonoff's Secret
Nov 9 at 17:54
3
Is this a real problem you are facing or just a thought expirement?
– whatsisname
2 days ago
1
@whatsisname I stated that in a previous comment, it's just an experiment
– FireCubez
2 days ago
83
83
Why can't you just use TLS? There's really no other way to do it securely.
– AndrolGenhald
Nov 9 at 13:58
Why can't you just use TLS? There's really no other way to do it securely.
– AndrolGenhald
Nov 9 at 13:58
4
4
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer
– FireCubez
Nov 9 at 13:59
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer
– FireCubez
Nov 9 at 13:59
1
1
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical.
– Solomonoff's Secret
Nov 9 at 17:54
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical.
– Solomonoff's Secret
Nov 9 at 17:54
3
3
Is this a real problem you are facing or just a thought expirement?
– whatsisname
2 days ago
Is this a real problem you are facing or just a thought expirement?
– whatsisname
2 days ago
1
1
@whatsisname I stated that in a previous comment, it's just an experiment
– FireCubez
2 days ago
@whatsisname I stated that in a previous comment, it's just an experiment
– FireCubez
2 days ago
|
show 7 more comments
11 Answers
11
active
oldest
votes
up vote
105
down vote
accepted
You can't.
To securely send information over an unsecure channel, you need encryption.
Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].
That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.
[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
23
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
1
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
5
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
add a comment |
up vote
43
down vote
TLS is really the only way to do it.
But what if I encrypt it with JavaScript?
The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered.
Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts.
Glad you're using modern tools to help protect your site, but SRI in a non-secure context really only protects against the compromise of an external resource. An attacker can simply modify the CSP headers and SRI tags.
There's really no way to do this without using encryption from the beginning, and the only standard way to do that is to use TLS.
add a comment |
up vote
26
down vote
While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange.
It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password. Since deriving the proof uses a nonce from the client and server, it's not something that can be reused by an attacker (like sending the hash itself would be).
This has a few added benefits to using HTTPS with the basic authentication you describe:
- The server never actually sees your password as you log in. If someone has managed to insert malicious code onto the server, they still won't know what your password is.
- If there is a bug in the HTTPS implementation (think Heartbleed), attackers still won't be able to acquire your password. Because, even once TLS is bypassed, the password isn't available.
- If, for some reason, you can't use HTTPS, this is better than sending the password in the clear. An attacker will not be able to guess your password based on the exchange. That said, you should still use HTTPS, because defense in depth is better.
Please note that this is only secure if the client is able to perform the SCRAM computations without downloading code from the server. You could provide a fat client, or users may be able to write their own code that they control. Downloading the SCRAM code over HTTP would give an attacker an opportunity to modify the SCRAM code to send the password in cleartext, or otherwise expose it.
New contributor
10
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
2
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
1
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
2
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
|
show 5 more comments
up vote
7
down vote
You should definitely deploy TLS in this case.
If you decide to try to invent a transport security system over HTTP, ultimately you're going to end up implementing a susbset of the TLS functionality anyway. There are many pitfalls to be aware of when designing and implementing such a system, which are further amplified when you choose to try to implement the system with a language that doesn't offer many safety features.
Even if you did implement a correct implementation of a cryptographic protocol in JavaScript (which is already a big challenge) you can't rely upon that implementation being resistant to timing attacks, and the whole thing breaks if someone has scripts disabled (e.g. with NoScript).
As a general rule you should choose the implementation that consists of the most simple, well-understood, trusted components that require you to write the least amount of security-critical code. To quote Andrew Tannenbaum:
A substantial number of the problems (in application security) are caused by buggy software, which occurs because vendors keep adding more and more features to their programs, which inevitably means more code and thus more bugs.
add a comment |
up vote
6
down vote
Do I need to implement some encryption algorithm like RSA public key encryption?
If you're considering trying that, you may as well just go the full mile and use HTTPS. Since you don't seem to be an expert, "rolling your own" encryption will undoubtedly have misimplementations that render it insecure.
add a comment |
up vote
2
down vote
There is actually a way to authenticate a user over an insecure connection: Secure Remote Password (SRP) protocol. SRP is specifically designed to allow a client to authenticate itself to a server without a Man-in-the-Middle attacker being able to capture the client's password, or even replay the authentication to later impersonate the client, whether the authentication succeeded or not. Furthermore, successful authentication with SRP creates a shared secret key that both the client and the server know, but a MitM does not. This secret key could be used for symmetric encryption and/or HMACs.
However, there are a number of limitations of SRP:
- The user must have registered in some secure fashion, as the registration process does require transmitting password-equivalent material (though the server does not need to store it).
- Although it is safe to attempt an SRP login with an untrusted server (that is, it won't expose your password to that server, and you'll be able to tell that the server didn't have your password in its database), It's not safe to load a login web page from an untrusted server (it could send down a page that captures your every keystroke and sends it off somewhere).
- Although successful authentication via SRP generates a secure shared secret key, the code to actually use this key in a web app would need to be loaded from a server, and an attacker could tamper with that code to steal the symmetric key and make changes to the requests and responses.
In other words, while SRP can be useful in situations where you have a trusted client that doesn't need to download its code over the insecure connection and also you have some other secure way to register the user(s), SRP is not suitable for a web application. Web apps always download their code from the server, so if the connection to the server isn't secure, a MitM (or other network attacker, for example somebody spoofing DNS) can inject malicious code into the web app and there's nothing that you, the victim, can do about it. Once that code is there, it can capture any password or other data you enter, steal any key that is generated, and tamper with any requests you send or responses you receive without you even knowing.
add a comment |
up vote
2
down vote
It is actually quite possible.
Password has to be hashed on the client side, but not with a static function. The following method uses two steps, and is inspired by the Digest access authentication:
NOTE: The server keeps a HMAC of the Password and the corresponding Key (Digest);
- The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
- Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
- Server calculates: HMAC( Digest, Nonce ) and compares it to the received value.
This protects you against replay.
The main interest I see is not a protection against eavesdropping, but to be completely sure that the plaintext password will not be store on the server, not even in a system log (see Twitter or GitHub).
Note: HMAC can be replaced by PBKDF2.
New contributor
5
Then some attacker can inject some code to get the password directly from the<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).
– Gustavo Rodrigues
Nov 10 at 10:34
add a comment |
up vote
1
down vote
It is certainly possible to send a password securely using HTTP. There is even a standard for it. It's called HTTP-Digest
and it's defined in RFC 7616. It's been a part of the HTTP spec for quite a while. It was originally designed to use only the MD5 message-digest ("hashing") algorithm, but later revisions of the standard allow the client and server to negotiate which algorithm to use.
Unfortunately, there are many problems with HTTP-digest and the most glaring of them is that the server needs to have the password in cleartext. So while it's possible to communicate passwords securely using HTTP, it's not possible to securely-store passwords on the server while using it. So basically, it's not useful.
As others have said, it would be better to implement TLS because it solves multiple problems all at the same time, and it's fairly forward-compatible.
add a comment |
up vote
1
down vote
As others have said TLS! TLS! TLS! (and with decent key length too)
But if you have to to use HTTP and any server to implement, is this for programmatic use or human use?
If for human use, are you looking at basic authentication or form-based? And are your uses able to apply a little logic E.g. not for joe public to use.
Does anything else need to be protected, or just the password itself?
If so you may be able to look at:
- Use a one-time password pad/generator (RSA fobs ain't cheap, and if you've got that sort of money to spend then you can afford TLS)
- Some other 2-factor auth like SMS (not without it's own issues).
- A simple challenge/response mechanism to obfuscate the password, for example the page displays two numbers on it in the text (not blatantly labelled either), user has to start password with a simple calculation such as difference between the two numbers added to each digit of a PIN, maybe with random stuff before and/or and after, eg 98634572dkkgdld. Changing the challenge numbers should stop replay attacks that aren't tried instantly, but if an attacker can capture enough attempts they may be able to work it out. You can't put any obfuscation logic in user-facing script either 'cos that'll be seen and if the scheme is too complex your users will hate you even more.
I'd still so with TLS though, certificates are cheap (even free) these days so convoluted obfuscation schemes really have no reason to exist any more.
New contributor
add a comment |
up vote
-3
down vote
An alternative would be to set up a secure VPN to the destination server, and perform a HTTP login from there. A malicious man in the middle will therefore have to break the encryption on the VPN channel in order to attack the connection and retrieve the passwords.
However, in terms of end user usability, it's still not as good as HTTPS, since it requires them to setup and use a different channel with a different set of credentials.
2
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
1
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
add a comment |
up vote
-4
down vote
You need the recipient to send you his key. You can't randomly send someone encrypted info without them first providing you with their personal public key.
add a comment |
protected by Rory Alsop♦ 8 hours ago
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
11 Answers
11
active
oldest
votes
11 Answers
11
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
105
down vote
accepted
You can't.
To securely send information over an unsecure channel, you need encryption.
Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].
That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.
[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
23
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
1
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
5
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
add a comment |
up vote
105
down vote
accepted
You can't.
To securely send information over an unsecure channel, you need encryption.
Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].
That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.
[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
23
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
1
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
5
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
add a comment |
up vote
105
down vote
accepted
up vote
105
down vote
accepted
You can't.
To securely send information over an unsecure channel, you need encryption.
Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].
That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.
[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.
You can't.
To securely send information over an unsecure channel, you need encryption.
Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].
That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.
[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.
edited Nov 9 at 20:27
timothywalter
382
382
answered Nov 9 at 14:08
tim
22.8k65991
22.8k65991
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
23
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
1
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
5
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
add a comment |
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
23
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
1
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
5
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
Couldn't you hash it twice? Once on the client side, once on the server?
– Nathan Merrill
2 days ago
23
23
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
@NathanMerrill - Hashing the password on the client side just makes the hash the password (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the channel, or an attacker can impersonate both ends of the conversation, even without knowing the password.
– Clockwork-Muse
2 days ago
1
1
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after.
– noɥʇʎԀʎzɐɹƆ
yesterday
5
5
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them.
– tim
yesterday
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with.
– Anders
7 hours ago
add a comment |
up vote
43
down vote
TLS is really the only way to do it.
But what if I encrypt it with JavaScript?
The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered.
Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts.
Glad you're using modern tools to help protect your site, but SRI in a non-secure context really only protects against the compromise of an external resource. An attacker can simply modify the CSP headers and SRI tags.
There's really no way to do this without using encryption from the beginning, and the only standard way to do that is to use TLS.
add a comment |
up vote
43
down vote
TLS is really the only way to do it.
But what if I encrypt it with JavaScript?
The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered.
Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts.
Glad you're using modern tools to help protect your site, but SRI in a non-secure context really only protects against the compromise of an external resource. An attacker can simply modify the CSP headers and SRI tags.
There's really no way to do this without using encryption from the beginning, and the only standard way to do that is to use TLS.
add a comment |
up vote
43
down vote
up vote
43
down vote
TLS is really the only way to do it.
But what if I encrypt it with JavaScript?
The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered.
Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts.
Glad you're using modern tools to help protect your site, but SRI in a non-secure context really only protects against the compromise of an external resource. An attacker can simply modify the CSP headers and SRI tags.
There's really no way to do this without using encryption from the beginning, and the only standard way to do that is to use TLS.
TLS is really the only way to do it.
But what if I encrypt it with JavaScript?
The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered.
Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts.
Glad you're using modern tools to help protect your site, but SRI in a non-secure context really only protects against the compromise of an external resource. An attacker can simply modify the CSP headers and SRI tags.
There's really no way to do this without using encryption from the beginning, and the only standard way to do that is to use TLS.
answered Nov 9 at 14:09
AndrolGenhald
8,73641830
8,73641830
add a comment |
add a comment |
up vote
26
down vote
While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange.
It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password. Since deriving the proof uses a nonce from the client and server, it's not something that can be reused by an attacker (like sending the hash itself would be).
This has a few added benefits to using HTTPS with the basic authentication you describe:
- The server never actually sees your password as you log in. If someone has managed to insert malicious code onto the server, they still won't know what your password is.
- If there is a bug in the HTTPS implementation (think Heartbleed), attackers still won't be able to acquire your password. Because, even once TLS is bypassed, the password isn't available.
- If, for some reason, you can't use HTTPS, this is better than sending the password in the clear. An attacker will not be able to guess your password based on the exchange. That said, you should still use HTTPS, because defense in depth is better.
Please note that this is only secure if the client is able to perform the SCRAM computations without downloading code from the server. You could provide a fat client, or users may be able to write their own code that they control. Downloading the SCRAM code over HTTP would give an attacker an opportunity to modify the SCRAM code to send the password in cleartext, or otherwise expose it.
New contributor
10
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
2
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
1
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
2
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
|
show 5 more comments
up vote
26
down vote
While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange.
It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password. Since deriving the proof uses a nonce from the client and server, it's not something that can be reused by an attacker (like sending the hash itself would be).
This has a few added benefits to using HTTPS with the basic authentication you describe:
- The server never actually sees your password as you log in. If someone has managed to insert malicious code onto the server, they still won't know what your password is.
- If there is a bug in the HTTPS implementation (think Heartbleed), attackers still won't be able to acquire your password. Because, even once TLS is bypassed, the password isn't available.
- If, for some reason, you can't use HTTPS, this is better than sending the password in the clear. An attacker will not be able to guess your password based on the exchange. That said, you should still use HTTPS, because defense in depth is better.
Please note that this is only secure if the client is able to perform the SCRAM computations without downloading code from the server. You could provide a fat client, or users may be able to write their own code that they control. Downloading the SCRAM code over HTTP would give an attacker an opportunity to modify the SCRAM code to send the password in cleartext, or otherwise expose it.
New contributor
10
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
2
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
1
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
2
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
|
show 5 more comments
up vote
26
down vote
up vote
26
down vote
While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange.
It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password. Since deriving the proof uses a nonce from the client and server, it's not something that can be reused by an attacker (like sending the hash itself would be).
This has a few added benefits to using HTTPS with the basic authentication you describe:
- The server never actually sees your password as you log in. If someone has managed to insert malicious code onto the server, they still won't know what your password is.
- If there is a bug in the HTTPS implementation (think Heartbleed), attackers still won't be able to acquire your password. Because, even once TLS is bypassed, the password isn't available.
- If, for some reason, you can't use HTTPS, this is better than sending the password in the clear. An attacker will not be able to guess your password based on the exchange. That said, you should still use HTTPS, because defense in depth is better.
Please note that this is only secure if the client is able to perform the SCRAM computations without downloading code from the server. You could provide a fat client, or users may be able to write their own code that they control. Downloading the SCRAM code over HTTP would give an attacker an opportunity to modify the SCRAM code to send the password in cleartext, or otherwise expose it.
New contributor
While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange.
It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password. Since deriving the proof uses a nonce from the client and server, it's not something that can be reused by an attacker (like sending the hash itself would be).
This has a few added benefits to using HTTPS with the basic authentication you describe:
- The server never actually sees your password as you log in. If someone has managed to insert malicious code onto the server, they still won't know what your password is.
- If there is a bug in the HTTPS implementation (think Heartbleed), attackers still won't be able to acquire your password. Because, even once TLS is bypassed, the password isn't available.
- If, for some reason, you can't use HTTPS, this is better than sending the password in the clear. An attacker will not be able to guess your password based on the exchange. That said, you should still use HTTPS, because defense in depth is better.
Please note that this is only secure if the client is able to perform the SCRAM computations without downloading code from the server. You could provide a fat client, or users may be able to write their own code that they control. Downloading the SCRAM code over HTTP would give an attacker an opportunity to modify the SCRAM code to send the password in cleartext, or otherwise expose it.
New contributor
edited yesterday
New contributor
answered Nov 9 at 18:01
Melanie
36114
36114
New contributor
New contributor
10
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
2
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
1
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
2
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
|
show 5 more comments
10
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
2
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
1
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
2
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
10
10
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them.
– Zoltan
Nov 9 at 19:07
2
2
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial.
– Melanie
Nov 9 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it.
– Zoltan
Nov 9 at 19:29
1
1
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free.
– Duncan X Simpson
Nov 10 at 4:30
2
2
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: HTTP Digest Authentication, so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application).
– Jost
yesterday
|
show 5 more comments
up vote
7
down vote
You should definitely deploy TLS in this case.
If you decide to try to invent a transport security system over HTTP, ultimately you're going to end up implementing a susbset of the TLS functionality anyway. There are many pitfalls to be aware of when designing and implementing such a system, which are further amplified when you choose to try to implement the system with a language that doesn't offer many safety features.
Even if you did implement a correct implementation of a cryptographic protocol in JavaScript (which is already a big challenge) you can't rely upon that implementation being resistant to timing attacks, and the whole thing breaks if someone has scripts disabled (e.g. with NoScript).
As a general rule you should choose the implementation that consists of the most simple, well-understood, trusted components that require you to write the least amount of security-critical code. To quote Andrew Tannenbaum:
A substantial number of the problems (in application security) are caused by buggy software, which occurs because vendors keep adding more and more features to their programs, which inevitably means more code and thus more bugs.
add a comment |
up vote
7
down vote
You should definitely deploy TLS in this case.
If you decide to try to invent a transport security system over HTTP, ultimately you're going to end up implementing a susbset of the TLS functionality anyway. There are many pitfalls to be aware of when designing and implementing such a system, which are further amplified when you choose to try to implement the system with a language that doesn't offer many safety features.
Even if you did implement a correct implementation of a cryptographic protocol in JavaScript (which is already a big challenge) you can't rely upon that implementation being resistant to timing attacks, and the whole thing breaks if someone has scripts disabled (e.g. with NoScript).
As a general rule you should choose the implementation that consists of the most simple, well-understood, trusted components that require you to write the least amount of security-critical code. To quote Andrew Tannenbaum:
A substantial number of the problems (in application security) are caused by buggy software, which occurs because vendors keep adding more and more features to their programs, which inevitably means more code and thus more bugs.
add a comment |
up vote
7
down vote
up vote
7
down vote
You should definitely deploy TLS in this case.
If you decide to try to invent a transport security system over HTTP, ultimately you're going to end up implementing a susbset of the TLS functionality anyway. There are many pitfalls to be aware of when designing and implementing such a system, which are further amplified when you choose to try to implement the system with a language that doesn't offer many safety features.
Even if you did implement a correct implementation of a cryptographic protocol in JavaScript (which is already a big challenge) you can't rely upon that implementation being resistant to timing attacks, and the whole thing breaks if someone has scripts disabled (e.g. with NoScript).
As a general rule you should choose the implementation that consists of the most simple, well-understood, trusted components that require you to write the least amount of security-critical code. To quote Andrew Tannenbaum:
A substantial number of the problems (in application security) are caused by buggy software, which occurs because vendors keep adding more and more features to their programs, which inevitably means more code and thus more bugs.
You should definitely deploy TLS in this case.
If you decide to try to invent a transport security system over HTTP, ultimately you're going to end up implementing a susbset of the TLS functionality anyway. There are many pitfalls to be aware of when designing and implementing such a system, which are further amplified when you choose to try to implement the system with a language that doesn't offer many safety features.
Even if you did implement a correct implementation of a cryptographic protocol in JavaScript (which is already a big challenge) you can't rely upon that implementation being resistant to timing attacks, and the whole thing breaks if someone has scripts disabled (e.g. with NoScript).
As a general rule you should choose the implementation that consists of the most simple, well-understood, trusted components that require you to write the least amount of security-critical code. To quote Andrew Tannenbaum:
A substantial number of the problems (in application security) are caused by buggy software, which occurs because vendors keep adding more and more features to their programs, which inevitably means more code and thus more bugs.
answered Nov 9 at 18:31
Polynomial
96.1k30241328
96.1k30241328
add a comment |
add a comment |
up vote
6
down vote
Do I need to implement some encryption algorithm like RSA public key encryption?
If you're considering trying that, you may as well just go the full mile and use HTTPS. Since you don't seem to be an expert, "rolling your own" encryption will undoubtedly have misimplementations that render it insecure.
add a comment |
up vote
6
down vote
Do I need to implement some encryption algorithm like RSA public key encryption?
If you're considering trying that, you may as well just go the full mile and use HTTPS. Since you don't seem to be an expert, "rolling your own" encryption will undoubtedly have misimplementations that render it insecure.
add a comment |
up vote
6
down vote
up vote
6
down vote
Do I need to implement some encryption algorithm like RSA public key encryption?
If you're considering trying that, you may as well just go the full mile and use HTTPS. Since you don't seem to be an expert, "rolling your own" encryption will undoubtedly have misimplementations that render it insecure.
Do I need to implement some encryption algorithm like RSA public key encryption?
If you're considering trying that, you may as well just go the full mile and use HTTPS. Since you don't seem to be an expert, "rolling your own" encryption will undoubtedly have misimplementations that render it insecure.
answered Nov 9 at 16:03
Brian Williams
1964
1964
add a comment |
add a comment |
up vote
2
down vote
There is actually a way to authenticate a user over an insecure connection: Secure Remote Password (SRP) protocol. SRP is specifically designed to allow a client to authenticate itself to a server without a Man-in-the-Middle attacker being able to capture the client's password, or even replay the authentication to later impersonate the client, whether the authentication succeeded or not. Furthermore, successful authentication with SRP creates a shared secret key that both the client and the server know, but a MitM does not. This secret key could be used for symmetric encryption and/or HMACs.
However, there are a number of limitations of SRP:
- The user must have registered in some secure fashion, as the registration process does require transmitting password-equivalent material (though the server does not need to store it).
- Although it is safe to attempt an SRP login with an untrusted server (that is, it won't expose your password to that server, and you'll be able to tell that the server didn't have your password in its database), It's not safe to load a login web page from an untrusted server (it could send down a page that captures your every keystroke and sends it off somewhere).
- Although successful authentication via SRP generates a secure shared secret key, the code to actually use this key in a web app would need to be loaded from a server, and an attacker could tamper with that code to steal the symmetric key and make changes to the requests and responses.
In other words, while SRP can be useful in situations where you have a trusted client that doesn't need to download its code over the insecure connection and also you have some other secure way to register the user(s), SRP is not suitable for a web application. Web apps always download their code from the server, so if the connection to the server isn't secure, a MitM (or other network attacker, for example somebody spoofing DNS) can inject malicious code into the web app and there's nothing that you, the victim, can do about it. Once that code is there, it can capture any password or other data you enter, steal any key that is generated, and tamper with any requests you send or responses you receive without you even knowing.
add a comment |
up vote
2
down vote
There is actually a way to authenticate a user over an insecure connection: Secure Remote Password (SRP) protocol. SRP is specifically designed to allow a client to authenticate itself to a server without a Man-in-the-Middle attacker being able to capture the client's password, or even replay the authentication to later impersonate the client, whether the authentication succeeded or not. Furthermore, successful authentication with SRP creates a shared secret key that both the client and the server know, but a MitM does not. This secret key could be used for symmetric encryption and/or HMACs.
However, there are a number of limitations of SRP:
- The user must have registered in some secure fashion, as the registration process does require transmitting password-equivalent material (though the server does not need to store it).
- Although it is safe to attempt an SRP login with an untrusted server (that is, it won't expose your password to that server, and you'll be able to tell that the server didn't have your password in its database), It's not safe to load a login web page from an untrusted server (it could send down a page that captures your every keystroke and sends it off somewhere).
- Although successful authentication via SRP generates a secure shared secret key, the code to actually use this key in a web app would need to be loaded from a server, and an attacker could tamper with that code to steal the symmetric key and make changes to the requests and responses.
In other words, while SRP can be useful in situations where you have a trusted client that doesn't need to download its code over the insecure connection and also you have some other secure way to register the user(s), SRP is not suitable for a web application. Web apps always download their code from the server, so if the connection to the server isn't secure, a MitM (or other network attacker, for example somebody spoofing DNS) can inject malicious code into the web app and there's nothing that you, the victim, can do about it. Once that code is there, it can capture any password or other data you enter, steal any key that is generated, and tamper with any requests you send or responses you receive without you even knowing.
add a comment |
up vote
2
down vote
up vote
2
down vote
There is actually a way to authenticate a user over an insecure connection: Secure Remote Password (SRP) protocol. SRP is specifically designed to allow a client to authenticate itself to a server without a Man-in-the-Middle attacker being able to capture the client's password, or even replay the authentication to later impersonate the client, whether the authentication succeeded or not. Furthermore, successful authentication with SRP creates a shared secret key that both the client and the server know, but a MitM does not. This secret key could be used for symmetric encryption and/or HMACs.
However, there are a number of limitations of SRP:
- The user must have registered in some secure fashion, as the registration process does require transmitting password-equivalent material (though the server does not need to store it).
- Although it is safe to attempt an SRP login with an untrusted server (that is, it won't expose your password to that server, and you'll be able to tell that the server didn't have your password in its database), It's not safe to load a login web page from an untrusted server (it could send down a page that captures your every keystroke and sends it off somewhere).
- Although successful authentication via SRP generates a secure shared secret key, the code to actually use this key in a web app would need to be loaded from a server, and an attacker could tamper with that code to steal the symmetric key and make changes to the requests and responses.
In other words, while SRP can be useful in situations where you have a trusted client that doesn't need to download its code over the insecure connection and also you have some other secure way to register the user(s), SRP is not suitable for a web application. Web apps always download their code from the server, so if the connection to the server isn't secure, a MitM (or other network attacker, for example somebody spoofing DNS) can inject malicious code into the web app and there's nothing that you, the victim, can do about it. Once that code is there, it can capture any password or other data you enter, steal any key that is generated, and tamper with any requests you send or responses you receive without you even knowing.
There is actually a way to authenticate a user over an insecure connection: Secure Remote Password (SRP) protocol. SRP is specifically designed to allow a client to authenticate itself to a server without a Man-in-the-Middle attacker being able to capture the client's password, or even replay the authentication to later impersonate the client, whether the authentication succeeded or not. Furthermore, successful authentication with SRP creates a shared secret key that both the client and the server know, but a MitM does not. This secret key could be used for symmetric encryption and/or HMACs.
However, there are a number of limitations of SRP:
- The user must have registered in some secure fashion, as the registration process does require transmitting password-equivalent material (though the server does not need to store it).
- Although it is safe to attempt an SRP login with an untrusted server (that is, it won't expose your password to that server, and you'll be able to tell that the server didn't have your password in its database), It's not safe to load a login web page from an untrusted server (it could send down a page that captures your every keystroke and sends it off somewhere).
- Although successful authentication via SRP generates a secure shared secret key, the code to actually use this key in a web app would need to be loaded from a server, and an attacker could tamper with that code to steal the symmetric key and make changes to the requests and responses.
In other words, while SRP can be useful in situations where you have a trusted client that doesn't need to download its code over the insecure connection and also you have some other secure way to register the user(s), SRP is not suitable for a web application. Web apps always download their code from the server, so if the connection to the server isn't secure, a MitM (or other network attacker, for example somebody spoofing DNS) can inject malicious code into the web app and there's nothing that you, the victim, can do about it. Once that code is there, it can capture any password or other data you enter, steal any key that is generated, and tamper with any requests you send or responses you receive without you even knowing.
answered Nov 10 at 10:42
CBHacking
9,04711527
9,04711527
add a comment |
add a comment |
up vote
2
down vote
It is actually quite possible.
Password has to be hashed on the client side, but not with a static function. The following method uses two steps, and is inspired by the Digest access authentication:
NOTE: The server keeps a HMAC of the Password and the corresponding Key (Digest);
- The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
- Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
- Server calculates: HMAC( Digest, Nonce ) and compares it to the received value.
This protects you against replay.
The main interest I see is not a protection against eavesdropping, but to be completely sure that the plaintext password will not be store on the server, not even in a system log (see Twitter or GitHub).
Note: HMAC can be replaced by PBKDF2.
New contributor
5
Then some attacker can inject some code to get the password directly from the<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).
– Gustavo Rodrigues
Nov 10 at 10:34
add a comment |
up vote
2
down vote
It is actually quite possible.
Password has to be hashed on the client side, but not with a static function. The following method uses two steps, and is inspired by the Digest access authentication:
NOTE: The server keeps a HMAC of the Password and the corresponding Key (Digest);
- The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
- Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
- Server calculates: HMAC( Digest, Nonce ) and compares it to the received value.
This protects you against replay.
The main interest I see is not a protection against eavesdropping, but to be completely sure that the plaintext password will not be store on the server, not even in a system log (see Twitter or GitHub).
Note: HMAC can be replaced by PBKDF2.
New contributor
5
Then some attacker can inject some code to get the password directly from the<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).
– Gustavo Rodrigues
Nov 10 at 10:34
add a comment |
up vote
2
down vote
up vote
2
down vote
It is actually quite possible.
Password has to be hashed on the client side, but not with a static function. The following method uses two steps, and is inspired by the Digest access authentication:
NOTE: The server keeps a HMAC of the Password and the corresponding Key (Digest);
- The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
- Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
- Server calculates: HMAC( Digest, Nonce ) and compares it to the received value.
This protects you against replay.
The main interest I see is not a protection against eavesdropping, but to be completely sure that the plaintext password will not be store on the server, not even in a system log (see Twitter or GitHub).
Note: HMAC can be replaced by PBKDF2.
New contributor
It is actually quite possible.
Password has to be hashed on the client side, but not with a static function. The following method uses two steps, and is inspired by the Digest access authentication:
NOTE: The server keeps a HMAC of the Password and the corresponding Key (Digest);
- The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
- Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
- Server calculates: HMAC( Digest, Nonce ) and compares it to the received value.
This protects you against replay.
The main interest I see is not a protection against eavesdropping, but to be completely sure that the plaintext password will not be store on the server, not even in a system log (see Twitter or GitHub).
Note: HMAC can be replaced by PBKDF2.
New contributor
edited Nov 10 at 15:29
emory
1,4881013
1,4881013
New contributor
answered Nov 10 at 9:38
Pierre del Perugia
371
371
New contributor
New contributor
5
Then some attacker can inject some code to get the password directly from the<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).
– Gustavo Rodrigues
Nov 10 at 10:34
add a comment |
5
Then some attacker can inject some code to get the password directly from the<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).
– Gustavo Rodrigues
Nov 10 at 10:34
5
5
Then some attacker can inject some code to get the password directly from the
<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).– Gustavo Rodrigues
Nov 10 at 10:34
Then some attacker can inject some code to get the password directly from the
<input>
. A crazy idea: "Sadly it's just a little bit hard to support HTTPS on Reserved IP addresses. Please run this code on your terminal and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run).– Gustavo Rodrigues
Nov 10 at 10:34
add a comment |
up vote
1
down vote
It is certainly possible to send a password securely using HTTP. There is even a standard for it. It's called HTTP-Digest
and it's defined in RFC 7616. It's been a part of the HTTP spec for quite a while. It was originally designed to use only the MD5 message-digest ("hashing") algorithm, but later revisions of the standard allow the client and server to negotiate which algorithm to use.
Unfortunately, there are many problems with HTTP-digest and the most glaring of them is that the server needs to have the password in cleartext. So while it's possible to communicate passwords securely using HTTP, it's not possible to securely-store passwords on the server while using it. So basically, it's not useful.
As others have said, it would be better to implement TLS because it solves multiple problems all at the same time, and it's fairly forward-compatible.
add a comment |
up vote
1
down vote
It is certainly possible to send a password securely using HTTP. There is even a standard for it. It's called HTTP-Digest
and it's defined in RFC 7616. It's been a part of the HTTP spec for quite a while. It was originally designed to use only the MD5 message-digest ("hashing") algorithm, but later revisions of the standard allow the client and server to negotiate which algorithm to use.
Unfortunately, there are many problems with HTTP-digest and the most glaring of them is that the server needs to have the password in cleartext. So while it's possible to communicate passwords securely using HTTP, it's not possible to securely-store passwords on the server while using it. So basically, it's not useful.
As others have said, it would be better to implement TLS because it solves multiple problems all at the same time, and it's fairly forward-compatible.
add a comment |
up vote
1
down vote
up vote
1
down vote
It is certainly possible to send a password securely using HTTP. There is even a standard for it. It's called HTTP-Digest
and it's defined in RFC 7616. It's been a part of the HTTP spec for quite a while. It was originally designed to use only the MD5 message-digest ("hashing") algorithm, but later revisions of the standard allow the client and server to negotiate which algorithm to use.
Unfortunately, there are many problems with HTTP-digest and the most glaring of them is that the server needs to have the password in cleartext. So while it's possible to communicate passwords securely using HTTP, it's not possible to securely-store passwords on the server while using it. So basically, it's not useful.
As others have said, it would be better to implement TLS because it solves multiple problems all at the same time, and it's fairly forward-compatible.
It is certainly possible to send a password securely using HTTP. There is even a standard for it. It's called HTTP-Digest
and it's defined in RFC 7616. It's been a part of the HTTP spec for quite a while. It was originally designed to use only the MD5 message-digest ("hashing") algorithm, but later revisions of the standard allow the client and server to negotiate which algorithm to use.
Unfortunately, there are many problems with HTTP-digest and the most glaring of them is that the server needs to have the password in cleartext. So while it's possible to communicate passwords securely using HTTP, it's not possible to securely-store passwords on the server while using it. So basically, it's not useful.
As others have said, it would be better to implement TLS because it solves multiple problems all at the same time, and it's fairly forward-compatible.
answered 2 days ago
Christopher Schultz
20718
20718
add a comment |
add a comment |
up vote
1
down vote
As others have said TLS! TLS! TLS! (and with decent key length too)
But if you have to to use HTTP and any server to implement, is this for programmatic use or human use?
If for human use, are you looking at basic authentication or form-based? And are your uses able to apply a little logic E.g. not for joe public to use.
Does anything else need to be protected, or just the password itself?
If so you may be able to look at:
- Use a one-time password pad/generator (RSA fobs ain't cheap, and if you've got that sort of money to spend then you can afford TLS)
- Some other 2-factor auth like SMS (not without it's own issues).
- A simple challenge/response mechanism to obfuscate the password, for example the page displays two numbers on it in the text (not blatantly labelled either), user has to start password with a simple calculation such as difference between the two numbers added to each digit of a PIN, maybe with random stuff before and/or and after, eg 98634572dkkgdld. Changing the challenge numbers should stop replay attacks that aren't tried instantly, but if an attacker can capture enough attempts they may be able to work it out. You can't put any obfuscation logic in user-facing script either 'cos that'll be seen and if the scheme is too complex your users will hate you even more.
I'd still so with TLS though, certificates are cheap (even free) these days so convoluted obfuscation schemes really have no reason to exist any more.
New contributor
add a comment |
up vote
1
down vote
As others have said TLS! TLS! TLS! (and with decent key length too)
But if you have to to use HTTP and any server to implement, is this for programmatic use or human use?
If for human use, are you looking at basic authentication or form-based? And are your uses able to apply a little logic E.g. not for joe public to use.
Does anything else need to be protected, or just the password itself?
If so you may be able to look at:
- Use a one-time password pad/generator (RSA fobs ain't cheap, and if you've got that sort of money to spend then you can afford TLS)
- Some other 2-factor auth like SMS (not without it's own issues).
- A simple challenge/response mechanism to obfuscate the password, for example the page displays two numbers on it in the text (not blatantly labelled either), user has to start password with a simple calculation such as difference between the two numbers added to each digit of a PIN, maybe with random stuff before and/or and after, eg 98634572dkkgdld. Changing the challenge numbers should stop replay attacks that aren't tried instantly, but if an attacker can capture enough attempts they may be able to work it out. You can't put any obfuscation logic in user-facing script either 'cos that'll be seen and if the scheme is too complex your users will hate you even more.
I'd still so with TLS though, certificates are cheap (even free) these days so convoluted obfuscation schemes really have no reason to exist any more.
New contributor
add a comment |
up vote
1
down vote
up vote
1
down vote
As others have said TLS! TLS! TLS! (and with decent key length too)
But if you have to to use HTTP and any server to implement, is this for programmatic use or human use?
If for human use, are you looking at basic authentication or form-based? And are your uses able to apply a little logic E.g. not for joe public to use.
Does anything else need to be protected, or just the password itself?
If so you may be able to look at:
- Use a one-time password pad/generator (RSA fobs ain't cheap, and if you've got that sort of money to spend then you can afford TLS)
- Some other 2-factor auth like SMS (not without it's own issues).
- A simple challenge/response mechanism to obfuscate the password, for example the page displays two numbers on it in the text (not blatantly labelled either), user has to start password with a simple calculation such as difference between the two numbers added to each digit of a PIN, maybe with random stuff before and/or and after, eg 98634572dkkgdld. Changing the challenge numbers should stop replay attacks that aren't tried instantly, but if an attacker can capture enough attempts they may be able to work it out. You can't put any obfuscation logic in user-facing script either 'cos that'll be seen and if the scheme is too complex your users will hate you even more.
I'd still so with TLS though, certificates are cheap (even free) these days so convoluted obfuscation schemes really have no reason to exist any more.
New contributor
As others have said TLS! TLS! TLS! (and with decent key length too)
But if you have to to use HTTP and any server to implement, is this for programmatic use or human use?
If for human use, are you looking at basic authentication or form-based? And are your uses able to apply a little logic E.g. not for joe public to use.
Does anything else need to be protected, or just the password itself?
If so you may be able to look at:
- Use a one-time password pad/generator (RSA fobs ain't cheap, and if you've got that sort of money to spend then you can afford TLS)
- Some other 2-factor auth like SMS (not without it's own issues).
- A simple challenge/response mechanism to obfuscate the password, for example the page displays two numbers on it in the text (not blatantly labelled either), user has to start password with a simple calculation such as difference between the two numbers added to each digit of a PIN, maybe with random stuff before and/or and after, eg 98634572dkkgdld. Changing the challenge numbers should stop replay attacks that aren't tried instantly, but if an attacker can capture enough attempts they may be able to work it out. You can't put any obfuscation logic in user-facing script either 'cos that'll be seen and if the scheme is too complex your users will hate you even more.
I'd still so with TLS though, certificates are cheap (even free) these days so convoluted obfuscation schemes really have no reason to exist any more.
New contributor
New contributor
answered yesterday
user211198
111
111
New contributor
New contributor
add a comment |
add a comment |
up vote
-3
down vote
An alternative would be to set up a secure VPN to the destination server, and perform a HTTP login from there. A malicious man in the middle will therefore have to break the encryption on the VPN channel in order to attack the connection and retrieve the passwords.
However, in terms of end user usability, it's still not as good as HTTPS, since it requires them to setup and use a different channel with a different set of credentials.
2
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
1
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
add a comment |
up vote
-3
down vote
An alternative would be to set up a secure VPN to the destination server, and perform a HTTP login from there. A malicious man in the middle will therefore have to break the encryption on the VPN channel in order to attack the connection and retrieve the passwords.
However, in terms of end user usability, it's still not as good as HTTPS, since it requires them to setup and use a different channel with a different set of credentials.
2
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
1
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
add a comment |
up vote
-3
down vote
up vote
-3
down vote
An alternative would be to set up a secure VPN to the destination server, and perform a HTTP login from there. A malicious man in the middle will therefore have to break the encryption on the VPN channel in order to attack the connection and retrieve the passwords.
However, in terms of end user usability, it's still not as good as HTTPS, since it requires them to setup and use a different channel with a different set of credentials.
An alternative would be to set up a secure VPN to the destination server, and perform a HTTP login from there. A malicious man in the middle will therefore have to break the encryption on the VPN channel in order to attack the connection and retrieve the passwords.
However, in terms of end user usability, it's still not as good as HTTPS, since it requires them to setup and use a different channel with a different set of credentials.
answered Nov 9 at 23:17
March Ho
8571713
8571713
2
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
1
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
add a comment |
2
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
1
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
2
2
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
How is the DNS resolution protected? (1) Is the DNS resolver (a) local? (b) reachable by a secure link? (2)(a) Does resolution happen over the VPN? Is the authoritative DNS server reachable by the resolver by a secure link? (b) What happens if the DNS resolution occurs before the VPN is set-up? (c) Can false DNS results obtained before the VPN is set-up be cached? (3)(a) Does the resolver use DNSSEC? (b) How is validation failure treated by the resolver? DNS resolution can be secured, by it isn't trivial.
– curiousguy
2 days ago
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
@curiousguy The same can be said for HTTPS though, unless you manually verify the certificate.
– March Ho
yesterday
1
1
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
Unless you accept random unverified certs (by clicking through any alert box), or cert authorities get hacked (possible, but doesn't happen every day), or they are totally incompetent (also possible, but errors can be detected and revoked), when do you need to "manually verify the certificate"?
– curiousguy
22 hours ago
add a comment |
up vote
-4
down vote
You need the recipient to send you his key. You can't randomly send someone encrypted info without them first providing you with their personal public key.
add a comment |
up vote
-4
down vote
You need the recipient to send you his key. You can't randomly send someone encrypted info without them first providing you with their personal public key.
add a comment |
up vote
-4
down vote
up vote
-4
down vote
You need the recipient to send you his key. You can't randomly send someone encrypted info without them first providing you with their personal public key.
You need the recipient to send you his key. You can't randomly send someone encrypted info without them first providing you with their personal public key.
answered 2 days ago
Tomachi
982
982
add a comment |
add a comment |
protected by Rory Alsop♦ 8 hours ago
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
83
Why can't you just use TLS? There's really no other way to do it securely.
– AndrolGenhald
Nov 9 at 13:58
4
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer
– FireCubez
Nov 9 at 13:59
1
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical.
– Solomonoff's Secret
Nov 9 at 17:54
3
Is this a real problem you are facing or just a thought expirement?
– whatsisname
2 days ago
1
@whatsisname I stated that in a previous comment, it's just an experiment
– FireCubez
2 days ago