I am using the basic-auth twitter API (no longer available) to integrate twitter with my blog's commenting system. The problem with this and many other web APIs out there is that they require the user's username and password to do anything useful. I don't want to deal with the hassle and cost of installing a SSL certificate, but I also don't want passwords passed over the wire in clear text.
I guess my general question is: How can I send sensitive data over an insecure channel?
This is my current solution and I'd like to know if there are any holes in it:
Generate a random key on the server (I'm using php).
Save the key in a session and also output the key in a javascript variable.
On form submit, use Triple DES in javascript with the key to encrypt the password.
On the server, decrypt the password using the key from the session and then destroy the session.
The end result is that only the encrypted password is sent over the wire and the key is only used once and never sent with the password. Problem solved?
Generate a random key on the server (I'm using php).
Save the key in a session and also output the key in a javascript variable.
On form submit, use Triple DES in javascript with the key to encrypt the password.
This avoids sending the password in the clear over the wire, but it requires you to send the key in the clear over the wire, which would allow anyone eavesdropping to decode the password.
It's been said before and I'll say it again: don't try to make up your own cryptographic protocols! There are established protocols out there for this kind of thing that have been created, peer reviewed, beat on, hacked on, poked and prodded by professionals, use them! No one person is going to be able to come up with something better than the entire cryptographic and security community working together.
Your method has a flaw - if someone were to intercept the transmission of the key to the user and the user's encrypted reply they could decrypt the reply and obtain the username/password of the user.
However, there is a way to securely send information over an unsecure medium so long as the information is not capable of being modified in transit known as the Diffie-Hellman algorithm. Basically two parties are able to compute the shared key used to encrypt the data based on their conversations - yet an observer does not have enough information to deduce the key.
Setting up the conversation between the client and the server can be tricky though, and much more time consuming than simply applying SSL to your site. You don't even have to pay for it - you can generate a self-signed certificate that provides the necessary encryption. This won't protect against man-in-the-middle attacks, but neither will the Diffie-Hellman algorithm.
You don't have to have a certificate on your server; it's up to the client whether they are willing to talk to an unauthenticated server. Key agreement can still be performed to establish a private channel. It wouldn't be safe to send private credentials to an unauthenticated server though, which is why you don't see SSL used this way in practice.
To answer your general question: you just send it. I think your real general question is: “How do I send sensitive data over an insecure channel—and keep it secure?” You can't.
It sounds like you've decided that security isn't worth the $10–20 per month a certificate would cost, and to protect Twitter passwords, that's probably true. So, why spend time to provide the illusion of security? Just make it clear to your users that their password will be sent in the clear and let them make their own choice.
So how is this any more secure? Even though you might have secured browser<>your server, what about the rest of the Internet (your server<>twitter)?
IMHO, it's unacceptable to ask for a username and password of another service and expect people to enter that. And if you care that much - don't integrate them until they get their act straight and re-enable OAuth. (They supported it for a while, but disabled it a few months ago.)
In the mean time, why not offer OpenID? Every Google, Yahoo!, VOX etc. account has one. People might not be aware of it but chances are really, really high that they already have OpenID. Check this list to see what I mean.
When the key is sent between the client and the server it is clear text and subject to interception. Combine that with the encrypted text of the password and the password is decrypted.
Diffie-Hellman is a good solution. If you only need to authenticate them, and not actually transmit the password (because the password is already stored on the server) then you can use HTTP Digest Authentication, or some variation there of.
APIs and OAuth
Firstly, as others have said, you shouldn't be using a user's password to access the API, you should be getting an OAuth token. This will allow you to act on that user's behalf without needing their password. This is a common approach used by many APIs.
Key Exchange
If you need to solve the more general problem of exchanging information over insecure connections, there are several key exchange protocols as mentioned by other answers.
In general key exchange algorithms are secure from eavesdroppers, but because they do not authenticate the identity of the users, they are vulnerable to man-in-the-middle attacks.
From the Wikipedia page on Diffie Hellman:
In the original description, the
Diffie–Hellman exchange by itself does not provide authentication of
the communicating parties and is thus vulnerable to a
man-in-the-middle attack. A person in the middle may establish two
distinct Diffie–Hellman key exchanges, one with Alice and the other
with Bob, effectively masquerading as Alice to Bob, and vice versa,
allowing the attacker to decrypt (and read or store) then re-encrypt
the messages passed between them. A method to authenticate the
communicating parties to each other is generally needed to prevent
this type of attack. Variants of Diffie-Hellman, such as STS, may be
used instead to avoid these types of attacks.
Even STS is insecure in some cases where an attacker is able to insert their own identity (signing key) in place of either the sender or receiver.
Identity and Authentication
This is exactly the problem SSL is designed to solve, by establishing a hierarchy of 'trusted' signing authorities which have in theory verified who owns a domain name, etc, someone connecting to a website can verify that they are indeed communicating with that domain's server, and not with a man-in-the-middle who has placed themselves in between.
You can create a self-signed certificate which will provide the necessary configuration to encrypt the connection, but will not protect you from man in the middle attacks for the same reason that unauthenticated Diffie-Hellman key exchange will not.
You can get free SSL certificates valid for 1 year from https://www.startssl.com/ - I use them for my personal sites. They're not quite as 'trusted' whatever that means, since they only do automatic checks on people who apply for one, but it's free. There are also services which cost very little (£10/year from 123-Reg in the UK).
I've implemented a different approach
Server: user name and password-hash stored in the database
Server: send a challenge with the form to request the password, store it in the session with a timestamp and the client's IP address
Client: hash the password, concat challenge|username|passwordhash, hash it again and post it to the server
Server: verify timestamp, IP, do the same concatenation/hashing and compare it
This applies to a password transmission. Using it for data means using the final hash as the encryption key for the plain text and generating a random initialization vector transmitted with the cipher text to the server.
Any comments on this?
The problem with client-side javascript security is that the attacker can modify the javascript in transit to a simple {return input;} thereby rendering your elaborate security moot. Solution: use browser-provided (ie. not transmitted) RSA. From what I know, not available yet.
How can I send sensitive data over an
insecure channel
With a pre-shared secret key. This is what you attempt in your suggested solution, but you can't send that key over the insecure channel. Someone mentioned DH, which will help you negotiate a key. But the other part of what SSL does is provide authentication, to prevent man-in-the-middle attacks so that the client knows they are negotiating a key with the person they intend to communicate with.
Chris Upchurch's advice is really the only good answer there is for 99.99% of engineers - don't do it. Let someone else do it and use their solution (like the guys who wrote the SSL client/server).
I think the ideal solution here would be to get Twitter to support OpenID and then use that.
An ssl certificate that is self-signed doesn't cost money. For a free twitter service, that is probably just fine for users.
TO OLI
In your approch for example i'm in the same subnet with same router, so i get the same ip as my collegues in my work. I open same url in browser, so server generates the timestamp with same ip, then i use tcp/ip dump to sniff the hashed or non hashed password from my collegues connection. I can sniff everything he sends. So i have all hashes from his form also you have timestamp(my) and same ip. So i send everything using post tool and hey i'm loggen in.
If you don't want to use SSL, why not try some other protocol, such as kerberos?
A basic overview is here:
http://www.kerberos.org/software/tutorial.html
Or if you want to go somewhat more in depth, see
http://www.hitmill.com/computers/kerberos.html
I have a similar issue(wanting to encrypt data in forms without paying for an ssl certificate) so I did some hunting and found this project: http://www.jcryption.org/
I haven't used it yet but it looks easy to implement and thought I'd share it here in-case anyone else is looking for something like it and finds themselves on this page like I did.
Related
I'm building a password manager site using nodejs on the back end. When the user registers and saves a password I encrypt it and then store it in the db, so it's safe. The problem is that I need a safe way to send it from the database and show it to the user when needed. Which is the best way, send it encrypted to the client and decrypt it with a script or decrypt on the back end before sending it? Is https safe enough to protect requests and responses?
Try encrypt and decrypt at device level, so the only risk you take is getting the master password. A good way to do that is with: https://nodejs.org/api/fs.html.
With FS can you write and read data from device level
When making decisions about cryptography, ask two essential questions:
What is your threat model?
Should you be implementing it yourself or use an existing solution (such as BitWarden, an open-source password manager)?
Your seemingly-simple question is tricky, because Web security in general is a complex topic. In an application such as yours, several layers are involved, and you must decide what to do about each of them in your threat model:
Client/browser
Front-end server
Back-end server (can be the same as the front-end server depending on architecture)
Database
Depending on who controls what, the answers will be different. For example, if you're developing a password manager to be deployed on a company's premises, then it likely won't matter whether you encrypt/decrypt on the "back-end" or on the "front-end", as they'll usually end up being the same host, managed by the same IT people. A compromise of the host can result in injecting malicious code, which can then intercept all passwords, keys, etc. right there in the browser, and it's little help that all crypto is done on the client when the client-side code is controlled by the attacker.
In such cases, what will matter more is policy decisions - e.g. if the passwords sometimes safeguard GDPR-subjected personal records, you may need to implement the principle of least privilege and make the journey of the plaintext passwords as short as possible - whether a server-hosted "site" can ever accomplish this becomes an organizational/legal question, rather than a technical one.
Analyze your threat model carefully - what attack scenarios are you defending against? Do different people own the DB layer and the back-end servers, or could a single person dump all DB data and undetectably replace the client-side JS? What do your defenses protect - data at rest, data in transit? You might find that, depending on your desired security properties, a Web-based password manager is not feasible. On the other hand, it may be that you're after simple, single-tier deployments, in which case your job is easier as you can do crypto on the back-end.
The least you could do, if you decide to roll your own password manager, is to look at existing software and learn from it. Pick something that has been audited (e.g. Bitwarden!), find the audit document, see what pitfalls the original authors had run into.
HTTPS is extremely scrutinized that you can assume it's safe, so long you can keep openssl on your system updated. And honestly, your password manager's implementation or maybe your DB/OS patch level is more likely be vulnerable to attacks.
But to answer your question. In theory, decrypting on client side could be safer, but that is only if the decryption truly happens on client side, and that the decryption key is never transmitted over the wire.
That way, even if somebody else gains access to the data or taps data in transit (even with HTTPS decrypted), they will not be able to decrypt it because they will not get the decryption key.
Afterall, that is basically end-to-end encryption like some messaging app does, just in asynchronous fashion.
And why not ask how others do it if you are doing it. For example, 1Password actually built their own protocol called Secure Remote Password (SRP) and they published a white paper detailing the exact intricacies. So you can definitely take reference.
As title shown,
Environment: password is already hash in database, and connection using HTTPS protocol
my question is simple, over the HTTPS, i saw some of the website using SSL, but also doing password encryption in frontend(client browser) when submit form.
Is require?
In my mind, since website is using SSL. there is no need to encrypt password in frontend(client browser). Because whatever frontend(client browser) doing, hacker also can do the same way by using the library(client browser imported the javascript hashing algorithn) to encrypt and send the token. Even put a salt also point less, it just a extra steps for hacker to encrypt it.
Unless the salt is come from other way, not from the same source(page rendering from server). example: from mobile, and using otp as a salt then can resolve.
else i don't think encryption is useful in frontend(client browser).
Am i correct? or i missed out somethings......
The problem is, a website doesn't have any alternatives but to trust in the HTTPS/SSL connection. Whatever encryption you do on client side (browser) will be done in JavaScript and this script must first be sent to the client. A ManInTheMiddle can just do the same as your client does, or he can simply remove the whole script.
It is the same problem you have, when you and your colleague try to invent a secret language, while the bad guy is listening. If you do not already share a secret, this is impossible. An SSL certificate solves this problem, because the browsers have built in a list of root certificates, which will act as the already shared secret.
The situation is a bit different for apps with a client and a server part. There you could install a secret key with your app, and based on this already shared secret you can establish a secure connection.
So the short answer is: yes it is ok to send the password plaintext, as long as the connection is encrypted with HTTPS/SSL.
I am submitting a form by using "POST" method. But, even I submit the form using "POST" method, I can see the submitted form data in http headers. Am using live http headers plugin to check the headers. I am trying to save secure info. If the browser has "live http headers" plugin, easily any one can trap the data. So, if I want to hide the submitted data in http headers also, what do I need to do?
If it is not possible to hide the submitted form data in http headers, which mechanism I could follow to encrypt the data at client side(so that even if data is visible in http headers, it would be in encrypted format. So, no one can understand) and decrypt and process the data at server side. I am totally blocked here.
Please help me out from this.
appreciate any help.
Thanks in advance.
There appears to be a bit of confusion regarding how an Http POST works. I'm assuming you are viewing the headers in either the client browser's debugger or on the server. In that case, the data being sent should be readable. The client side debugger actually displays the headers before they are encrypted and sent across the wire.
On the server, the post data should also be available in unencrypted format.
What is sent over the internet would be encrypted, provided that you are using https:// in your form action instead of http://
You can't really do that, I mean you could but anything on the front end can be easily reverse engineered. Your best bet for securing form data is to implement CSRF of which Jeff Atwood did a good post on here and the comments are quite good as well.
Aside from that; like one of the comments above says, you can use SSL to secure the data going to and from the server.
Comments weren't long enough for this
The steps towards getting secure, without knowing your technology stack would be to get an SSL certificate for the origin and destination of your post request, if you don't have control of the destination your journey ends here but head over to one of the hundreds of SSL certificate providers available, I usually use Start SSL because it's free and pretty good.
You'll need to give us some more info on your technology stack to go any further but assuming you're using PHP and Apache you'll need to do a few things on your server to get the certificate.
Firstly generate your Private Key using this command:
openssl genrsa -des3 -out www.yourdomainname.com.key 2048
It will ask you for a few details, fill them all out as best you can and write them down somewhere, specifically the password.
Once you have this, you need to generate a certificate signing request or a CSR for short, this is achieved by running the below command
openssl req -new -key www.yourdomainname.com.key -out www.yourdomainname.com.csr
The password you entered to create the private key, when it asks; enter it here.
You'll also be asked for a load of details, from my memory this is what it will ask and it's generic format
Country Name: GB
State or Province Name (in full): London
Locality Name (city): London
Organization Name: Your company name
Organizational Unit Name: Probably IT or development
Common Name: Enter your domain name here in FULL, without http://
When it asks for
Email Address
password challenge
optional company name
don't enter anything...
validate your CSR using
openssl req -noout -text -in www.mydomain.com.csr
You can now use this CSR to sign your request with Start SSL Once you have your crt from Start SSL open your server config (with apache its usually http-vhosts.conf in /etc/apache2/extra/ and create this block inside of it
<VirtualHost *:443>
DocumentRoot /var/www/www.yourdomainname.com
ServerName www.yourdomainname.com
SSLEngine on
SSLCertificateFile /path/to/your/www.yourdomainname.com.crt
SSLCertificateKeyFile /path/to/your/www.yourdomainname.com.key
SSLCertificateChainFile /path/to/StartSSL.crt
</VirtualHost>
Restart apache and you should be able to access your website using https
Hopefully I've got that all correct, I'll edit for any issues.
Well, there is no easy way but from other posts that I have found:
Take a look at this post. This does not hide the values in POST but using jquery serializes them. You can use your own conventions to make it look like a mess.
Take a look at this article. CLearly explains everything you should know about cross site request forgery.
Have a look at this link. They provide a toolkit to use encrypted forms, called Open Data Kit.
Are you using OpenSSL?
The simplest solution is to enable HTTPS support on your server, and serve the pages only via HTTPS, by turning off the standard HTTP connector.
You won't have to any special development, just switching to HTTPS will ensure that the data cannot be read in transit, and gives the assurance to the viewers of your pages that it's really your server that they are talking with, and not someone doing a man-in-the-middle attack.
The HTTPS technology transparently handles all the concerns that you are trying to handle manually. The browser will exchange with the server a temporary encryption key that is used to encrypt all data sent data back and forth.
The server contains a certificate signed by a certificate authority that is used to sign the data, to prove to browsers that it's really your server.
All of this is handled in a completely transparent and automated way, without any extra development. You just need to contact a certificate authority and get them to create you a certificate, see this tutorial.
You also need to enable HTTPS on the server, this is done via configuration and all servers support it.
A "header" is just another encapsulation. There is no difference between that and the abstract idea of "body". One is not inherently more or less safe for carrying data over wire, so your focus should not be on solving this issue. Also, post data technically is in the body.
If security is your objective here, then you will focus on preventing what someone could do if they had privilege in your client/server exchange. Then you would use SSL, http-only cookies (or well thought-out local storage) good session timeouts, and your usual smart coding practices. Generally we should assume most data is viewable in transit, and prioritize against making that privilege even worthwhile for an attacker
If you were really that truly concerned about MITM attacks against your form post data, I suppose you could throw together a little JS to encrypt and maybe even post over web-sockets, but that's akin to not really doing anything at all IMHO.
My security knowledge is kind of limited but I might learn something.I´m planning to create an ajax application where I encrypt/decrypt passwords client-side with a typed master password
using a javascript AES library and then send/retrieve the encrypted data to/from Google App Engine(user authenticated). I actually found a project with the same idea: http://code.google.com/p/safety-vault/
In my mind as long as I keep my local computer secure (keyloggers) this should be quite secure or am I missing something?
As long as you use SSL for the webapp, this should be fine. Without SSL, an attacker could modify the page to insert some Javascript that sends them your password when you type it.
You might want to reconsider your threat model, though. Do you trust the server? If not, you shouldn't trust it to not send you a page that captures your master password when you enter it. If you do, you shouldn't have any qualms in sending your master password to the server.
There is a problem here, as I assume at some point you're going to have to send your master password to the browser client? If you have the master password, then you can decrypt the stream you send...
Use HTTPS, it's what it was designed for.
You effectively are trusting Google App Engine employees, and transitively, the entire trust chain behind them, to not steal your passwords. Encrypting client side doesn't mean anything if you are executing JavaScript code the server sends you, furthermore if you have no HTTPS implemented properly, it's trivial for someone to do a man in the middle attack and steal your passwords as they are transmitted. Just store the passwords locally or encrypt them with a well known tool like GPG and upload them.
I'm wondering what the serious issues are with the following setup:
Username/password login scheme
Javascript/ajax requests the salt value from the server (we have established in previous questions salt is not a secret value)
Javascript preforms an SHA1 (or otherwise) of the password and salt.
Javascript/ajax return the hash to the server
The server applies another salt/hash on-top of the the one sent via ajax.
Transactions are over HTTPS.
I'm concerned about problems that may exist but can't convince myself that this is that bad of a setup. Assume that all users need javascript enabled as jQuery is heavily used on the site. It's basically attempting to add an additional layer of security to the plain-text of a password.
As always: be very careful about designing cryptographic protocols yourself.
But that being said, I can see the advantage in the scheme. It will protect against the password being revealed through a man-in-the-middle-attack and it will ensure that the server never sees the actual password, thus preventing some inside attacks. On the other hand it does not protect against man-in-the-browser, fishing etc.
You might want to read through RFC 2617 about HTTP Digest access authentication. That scheme is similar to what you propose.
All that effort of passing salts and hashes between the client and server is already built into the underlying HTTPS/SSL protocol. I would be very surprised if a security layer in javascript is going to help very much. I recommend keeping it simple and use plaintext over SSL on the client-side. Worry about encryption on the server-side.
This doesn't add any additional security. The JavaScript code is present in the client, so the hashing algorithm is known. You gain nothing from doing a client-side hash in this case.
Also, there's no reason why the client should know about the hashing salt. It actually should be a secret value, especially if you're using a shared salt.
I'll 100% disagree with the accepted answer and say that under no circumstances should an original password ever Ever EVER leave the client. It should always be salted and hashed. Always, without exception.
Two reasons...
. The client should not be relying that all the server components and internal networks are TSL. It is quite common for the TSL endpoint to be a load balancing reverse proxy, which communicates with app servers using plaintext because devops can't be bothered to generate server certs for all their internal servers.
. Many users are pathologically inclined to use a common password for all of their services. The fact that a server has plaintext passwords, even if only in memory, makes it an attractive target for external attack.
You're not gaining anything. There's no point to a salt if Joe Public can see it by clicking View > Source, and the old maxim about never trusting client input goes double for password hashing.
If you really want to increase security, use a SHA-2 based hash (SHA-224/256/384/512), as SHA-1 has potential vulnerabilities. NIST no longer recommends SHA-1 for applications that are vulnerable to collision attacks (like password hashes).