Extra security

I'm tasked with creating a secure form. From my understanding what they want is to replace what they're using to encrypt traffic before sending it over an encrypted tunnel and automate the whole process.

So my proof of concept to show them for funding purposes could take the data from an HTML form submissoin, encrypt it using an AES cipher and then pass it along an SSL tunnel.

I have a plan to implement a dynamic cipher so that each session could encrypt the same data but encrypt it completely differntly and it would be completely reversable since the server would be generating the code to cypher for each session.

Encrypting an HTML form submission using JavaScript doesn't provide any security benefit over SSL. The reason is very simple: the level of access that an attacker needs to compromise an SSL connection is greater than the level of access they need to compromise your JavaScript. Thus, if your SSL is compromised, your JavaScript is also already compromised. This is true for attacks on both the client side and the server side, as well as for man-in-the-middle attacks.

If you use a browser extension to do the encryption and the decryption, then it does add an additional layer of security (as long as the server is physically incapable of decrypting the data).

Thanks. I agree with most of what you said but my idea is to dynamically encrypt. I believe Wireshark has built in functionality to decrypt SSL conversations, but it wouldn't have built in functionality to decrypt my dynamic encryption algorithm so manually rever engineering it would be required. And because it's dynamic, each request would have to be reverse engineered.

Imagine a page that when the page is requested, starts a session ID and then based on the request time, stored in a database linking it to the session ID, a dynamic encryption algorithm is generated and served as a JavaScript function.

Every request generates a new algorithm, and session ID and thus the encryption would be different every time the request is made.

If a network were compromised, for example, and all traffic on the wireless network were intercepted by the attacker and pushed into wireshark, an SSL encrypted conversaion would be as good as plain text, whereas a dynamically encrypted conversation would require manual labour and since it's different for each request, it would be extra secure.

As I mentioned above, more than 50% of the networks around me are WEP or less. Wireless interception would be easier than a system. It wouldn't be impossible but the amount of data and requests would make it much more difficult.

It could be argued that a plugin would be less secure than dynamic JavaScript because, the attacker, knowing the traffic they're looking for, would just have to download and reverse engineer the plugin to get the algorithm.

Part of the idea is to hash some data and have a small rainbow tables that represents all the possible value and hash combinations on the server. This would be useful for things such as phone numbers, or social security numbers. The pre-hashed data could then be used to encrypt the data and since over the network the hashed data is unknown, it would be impossible to reverse the cipher to get the data without knowing some of the data already. Think dynamic public key.

Wireshark can only decrypt SSL data if supplied with the RSA key used to establish the connection. (And if your server's private key is compromised you've already lost everything.)

Furthermore, if you're not trusting the connection, nothing you do in javascript has any value. The attacker can simply read your javascript function when it's sent to the client (and if he can alter the packets, can substitute his own javascript function).

The non-existence of tools that decrypt your personal encryption method is not a benefit. Modern encryption algorithms are designed to be secure even with the implementation known as long as the key is secure and have been extensively analyzed with this in mind. A home-brew algorithm is much more likely to contain flaws that make it insecure. (And if that wasn't bad enough, since there isn't a standard, trusted implementation on the client already, you're opening a new attack vector when you send the client your algorithm.)

If the server needs access to the plaintext data, sending it over properly-implemented SSL is as secure as your server is. If the server doesn't need access to the plaintext, E-Oreo's suggestion of encrypting on the host with an trusted third party tool can add a little protection.

I believe Wireshark has built in functionality to decrypt SSL conversations, but it wouldn't have built in functionality to decrypt my dynamic encryption algorithm so manually rever engineering it would be required.

Oh boy.

Do you have any idea what TLS/SSL is and how it works? Do you think the millions of people, companies and organizations using it every day do that just for fun? And only you know how to do proper encryption?

If you can decrypt TLS traffic with Wireshark (wut?), get ready to win the Fields Medal, the Turing Award and several million dollars all at the same time. You've just turned the world on its head. Mathematics and computer science have to be rewritten, and pretty much any computer and any piece of data on this planet is no longer secure -- until WrinkledCheese with his JavaScript voodoo comes to save us.

You need to stop watching bad movies and start informing yourself before you talk about things. No, Wireshark cannot decrypt TLS traffic -- unless you're willing to wait for several trillion years to decrypt a single TLS session.

Even the buggiest TLS implementation with the worst algorithm and the shortest key length is far, far better than anything you'll ever come up with. So do yourself a favor, stop fumbling with this JavaScript stuff and set up a proper TLS server -- like everybody else.

You wouldn't be the first person to stumble upon their genius home-made algorithm (which usually turns out to not be quite as genius).

Why canít I use certain words like "drop" as part of my Security Question answers?
There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

I believe Wireshark has built in functionality to decrypt SSL conversations

Wireshark would only be able to decrypt the traffic if you supplied it with the server's private key or configured it to act as a MITM. I don't use Wireshark much, but I do use Fiddler for debugging, which is a similar tool. Fiddler allows you to configure it to act as a MITM, which allows it to show you the plaintext of the packets being sent out over encrypted connections. I would not be surprised if Wireshark had a similar option.

However, that's actually besides the point. Doing what Wireshark does requires administrator access at the OS level. If your client system is compromised to that degree, then the attacker can acquire the plaintext values simply by reading them out of memory. They don't even need to capture the network traffic. Even SSL won't help you in that case; literally nothing will.

If the SSL connection is compromised somewhere between the client and the server, then the attacker can easily replace your JavaScript with their own as OmegaZero mentioned.

It could be argued that a plugin would be less secure than dynamic JavaScript because, the attacker, knowing the traffic they're looking for, would just have to download and reverse engineer the plugin to get the algorithm.

That would be difficult to argue because there are no accepted encryption algorithms that rely on the algorithm being secret. In fact, one of the fundamental defining criteria of a secure encryption algorithm is that knowing the algorithm doesn't help the attacker defeat it.

The point of this exercise is not to reinvent the wheel - no complex cipher math by me, I'm not a mathematician. The goal is to prevent some forms of simple attacks, especially when other easier targets exist. Hence it's extra, ontop of accepted standards. If someone wants it bad enough, they can get anything.

Omega Zero, E-Oreo,

Sure TLS is very strong, but it's not impregnable.

A Man-In-The-Middle Smith - henceforth known as Mr. Smith - sits in a cafe, airport, public access point, and waits for TLS traffic, thinking, TLS means goodies. Because the standard MITM fails, the payload is further encrypted. Mr. Smith says: "**** this!, there are 5 other TLS sessions available and they probably don't require this much work! I'll save it for later." But when he gets to check it out he got the first half of the conversation and it's nothing useful becasue he went to an easier attack.

Attack foiled.

You brought up a very good point, interjecting JavaScript as it's sent over to the client. But again, the attacker is expected to not expect this. The dynamic nature of the algorythm to encrypt - not an actual encryption algorythm but a iterance/algorythm-selection algorythm - is that it's thwarts some attacks. If someone wants data bad enough they will get it.

Originally Posted by E-Oreo

If the SSL connection is compromised somewhere between the client and the server, then the attacker can easily replace your JavaScript with their own as OmegaZero mentioned.

Yes, but the point of this is not to prevent an attack when TLS is compromised, it's to prevent an attack when another easier target is available, IE hot-spot or other wireless networks.

If there was a bag of money on a park bench with a chain on it and a bag of money on the bench next to it - also chained - with a nasty looking Cane Corso. Which would the attacker go for? TLS is the chain. My implementation is the Cane Corso. Sure you could throw the dog a steak and cut the chain, but why not just cut the chain on the other bench?

No security is removed from accepted practices, it's extra.

Jaques, you're just a flamer, but let me explain it to you nice and slow.

Step 1
SSL/TLS PHP Session, as per normal...I don't understand why you didn't get this. Maybe to throw in a breaker ball, the data, or even some of it, is submitted over SSH, just because it's different, yet just as secure as TLS, because they're essentially the same thing.

Components of the "algorithm", including many well established ciphers.

SHA512 hash data with small number(millions) of possibilities - rainbow tables for this hash, and salt, are on the server accepting the data. Think of the hash as a public key and the private key is the data that generated that hash. IE Phone number, Social Security Number, first characters of various fields, etc. The most sensitive information would be used. The dynamic part is which data to hash meaning different rainbow tables to look up to get the "private key" from. And maybe sometimes it's a SHA384 hash. Dynamic.

and the dynamic nature is based on the PHP Session ID, or something random but known, alternatig with - and referencing - the MAC, or other predetermined data. We can have all sorts of dynmaic funkyness. Especially when it's all salted by the "private key" data that is now transmitted as an SHA512 hash which we reverse with our server side rainbow tables.

You still with me Jaques, I know all my "complex" math is throwing you off. Maybe I throw in another double ROT13 just for you...****ing Jackass.

No, no awards expected - unless you're offering - just a lot of extra work if the attacker wants this data vs any other data plainly encrypted with just TLS.

[EIDT]
P.S.
The SSH, to some form of attacks, would be - due to obscurity - more secure, becaues Mr. Smith(see above example) is looking for TLS encrypted banking info, not SSH server credentials.

Unfortunately, this is just the usual mumbo-jumbo people come up with when they have a lot of creativity but very little technical understanding. This is voodoo crypto with a lot of wrong assumptions, buzzwords, random algorithms ("I'm gonna use TripleDESAES1337IPSec!!1"), big numbers and the inevitable security through obscurity ("If I don't tell anybody what I'm doing, people will have a hard time finding it out!!1").

OK, let's go through this one by one:

You somehow assume that anybody sitting in some cafe with their laptop can decrypt TLS traffic on the fly. You don't know what you're talking about. TLS isn't perfect, and there are several attack vectors on old versions of the protocol, but we're far, far from being able to simply read the traffic. Do you not think people would stop using TLS if that were the case?

You've fallen in love with your idea of "dynamic encryption". Do you understand why TLS transmits the selected cipher as plaintext? It's because the security of encryption depends on the key, not on hiding the algorithm. The key must be changed, not the cipher. How many ciphers can you choose from, anyway? 10 maybe? Wow, that will totally confuse the attackers.

I have a hard time following your weird protocol (especially since you seem to change it with every reply), but if I understand you correctly, you wanna use some "secret data" (like the telephone number) to generate the key. That would be pretty much the worst thing you could possibly do. Keys have to be random, they must not be based on any information whatsoever.

Long story short: What you have there is a bunker (the TLS connection) with a small sign saying "Please don't break in." (your stuff). Keep the bunker and throw away the sign.

Make sure both your server and the clients support TLS 1.2, choose a strong algorithm with forward secrecy and make sure to protect the key. That's it.

Why canít I use certain words like "drop" as part of my Security Question answers?
There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

My idea isn't bad, it won't replace TLS by a long shot and is only designed to take at least an hour to reverse engineer, but it's not bad, it doesn't reduce security, it increases it, even if only marginally.

If someone gets passed security(SSL or TLS) - IE man in the middle, old client browser not supporting the latest and greatest - and then has time to inject custom JS, instead of just picking another target, then they had it without my implementation anyway.

My idea is designed to give the attacker a choice, pick another target, continue with the non-standard implementation. It would also thwart any script kiddies with absolutely no programming knowledge.

I thought my idea was better before JS injection on a compromised TLS session was put forth.

Windows XP has reached end of life 4 years ago. The people still using it have far bigger problems than not getting the latest TLS version, because the best crypto won't help you if the PC itself is infected.

Originally Posted by WrinkledCheese

My idea isn't bad, it won't replace TLS by a long shot and is only designed to take at least an hour to reverse engineer, but it's not bad, it doesn't reduce security, it increases it, even if only marginally.

It (probably) doesn't reduce security, but it doesn't add any relevant security either. And it adds a lot of complexity.

The thing is this: Yes, you can do all kinds of things to get a little bit of extra security. You can use AES and ROT13. You can carry a gun and a toy knife. But how does that help you? The people you can stop are already stopped by AES and your gun. And the people determined enough to break AES and fight you despite the gun surely won't care about ROT13 and your toy knife. When somebody has spent or is willing to spend hours, days, years attacking you, and they're already at 99.9999%, why on earth would they stop at the last 0.0001%?

So this little bit of extra security just isn't relevant. It bloats your code, it stresses your CPU, it increases the bandwidth, but it doesn't do anything useful. It's grossly inefficient. It's like the people leaving out code comments to speed up the compiler.

Why canít I use certain words like "drop" as part of my Security Question answers?
There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

Windows XP has reached end of life 4 years ago. The people still using it have far bigger problems than not getting the latest TLS version, because the best crypto won't help you if the PC itself is infected.

I do have to say the JS injection is an issue to be solved. I wonder if they considered it.

Originally Posted by Jaques1

And it adds a lot of complexity.

That's the whole point.

Originally Posted by Jaques1

The thing is this: Yes, you can do all kinds of things to get a little bit of extra security. You can use AES and ROT13. You can carry a gun and a toy knife. But how does that help you? The people you can stop are already stopped by AES and your gun. And the people determined enough to break AES and fight you despite the gun surely won't care about ROT13 and your toy knife.

ROT 13 x2, or ROT26, think about it...
goad
/gōd/
Noun
A spiked stick used for driving cattle.
Verb
Provoke or annoy (someone) so as to stimulate some action or reaction.

Originally Posted by Jaques1

When somebody has spent or is willing to spend hours, days, years attacking you, and they're already at 99.9999%, why on earth would they stop at the last 0.0001%?

Not the type of attack I'm trying to prevent. Random sniff and interject attacks(cafe man-in-the-middle). The drive by attack.

Originally Posted by Jaques1

So this little bit of extra security just isn't relevant.

It is. Requireing time and effort instead of a preconfigured man in the middle attack.

Originally Posted by Jaques1

It bloats your code,

Oh no, a few dozen lines of code, couple hundred tops.

Originally Posted by Jaques1

it stresses your CPU,

I would like to see the benchmarks.

Originally Posted by Jaques1

it increases the bandwidth,

Bandwidth is free.

Originally Posted by Jaques1

but it doesn't do anything useful. It's grossly inefficient. It's like the people leaving out code comments to speed up the compiler.

Did oyu know some retail stores locations, IE Some WalMarts, look like they have hundreds of cameras ( black domes on the ceiling ) but in actuality they may only have a dozen or so. It's called a deterent.

You know that guy at the mall with a plastic badge, a flash light and the word security across the back of his law enforcement-esqe uniform.

de∑ter∑rent
/diˈtərənt/
Noun
A thing that discourages or is intended to discourage someone from some act.
Adjective
Able or intended to deter.

For a second, I actually thought you're willing to learn and give up stupid ideas. But that's obviously not the case.

Well, good luck with your project then. Let's just hope you won't encounter anybody with security knowledge, because if you do, you're in trouble. But in an environment relying on Windows XP and WEP you're probably safe from competence.

Why canít I use certain words like "drop" as part of my Security Question answers?
There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

The FACT of the matter is, in the world of security, the USER is the least secure. They have a virus, they have poor wireless encryption, the provide personal information over a wireless, public, albeit encrypted, network, they have weak passwords. On top of that, they don't upgrade their computer until it breaks, not because their TLS version is not supported. Any security mechanism you can think of, there are millions of people who have broken it.

You suggestion is to have security for the people who have the most modern computers and security, such as TLS.

You're en elitest, only the latest and greatest will suffice and anything else is just ****. In the words of that guy from fantastic four: on.

Originally Posted by Jacques1

For a second, I actually thought you're willing to learn and give up stupid ideas. But that's obviously not the case.

Well, good luck with your project then. Let's just hope you won't encounter anybody with security knowledge, because if you do, you're in trouble. But in an environment relying on Windows XP and WEP you're probably safe from competence.

...trying to explain anything to you is like telling a 2 year old not to touch.

Windows XP is still in widespread use, therefore it MUST be supported. WEP is still around, discouraged, but people use it. This MUST be taken into account. Even worse are open networks.

When I go to many government or public facility, some still have CRT monitors and most run Windows XP for their public terminals. Deal with the fact that your perfect scenario is not feasible in the real world.

Step B - Folks who know something about infosec kindly invest time and effort, trying to provide knowledge that might help the original poster (OP) toward the stated goal. Because of OP's ignorance (see A above), these responses usually attempt to correct various errors and misunderstandings.

Step C - OP bellicosely contradicts and criticizes the folks who are trying to help, insisting that their responses (which most often are learned and valid) are in some sense wrong.

Step E - OP escalates to name-calling against those who are trying to help, and/or personal criticism. Usually, OP suggests that the responses to his/her posts are motivated by some malevolent purpose.

Now, I'm perfectly free to consult a physician about my medical complaint, and then to tell her that she doesn't know jack sh*t about medicine. However, I don't exercise this freedom, and a few moments' thought might suggest some of the good reasons why I don't.

Please note that when I use the word "ignorant," I mean no personal criticism. All of us are ignorant about almost everything -- our knowledge can encompass only a little sliver of what is possible to know. Ignorance is a starting point of learning, and is a great condition to be in, provided it is accompanied by humility.