Thread: Extra security

Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    158
    Rep Power
    98

    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.

    Comment and suggestions appreciated.

    P.S. what ungodly hour is this?
  2. #2
  3. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,316
    Rep Power
    7171
    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).
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  4. #3
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    158
    Rep Power
    98
    E-Oreo,

    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.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    May 2007
    Posts
    765
    Rep Power
    929
    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.
    sub{*{$::{$_}}{CODE}==$_[0]&& print for(%:: )}->(\&Meh);
  8. #5
  9. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by WrinkledCheese
    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).
    Last edited by Jacques1; August 1st, 2013 at 06:56 PM.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    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".
  10. #6
  11. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,316
    Rep Power
    7171
    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.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  12. #7
  13. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    158
    Rep Power
    98
    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.

    Step 2
    Before response sent, generate dynamic encryption aka "My Plan."

    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.

    Encrypting the rest of the data sample idea. Something dynamic and unique to a client, IE MAC and PHP Session ID.
    PHP Session ID: PHP_SESSION_1a2b3c4d
    MAC Address 12:34:56:ab:cd:ef (sent with TLS encrypted request)

    Drop off "PHP_SESSION_" sometimes, based on some dynamic factor.

    For this session:
    PHP SESSION ID generated string "1" = AES 173 times
    PHP SESSION ID generated string "2" = TrippleDES 371 times
    ...
    PHP SESSION ID generated string "b", preceeded by 2 and preceeding 3 = ROT13 2 times <- just for you Jaques.

    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.

    ..mgiht as well throw some IPSec in there too.
    Last edited by WrinkledCheese; August 2nd, 2013 at 12:14 AM.
  14. #8
  15. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Thanks, my coworkers and I had a good laugh.

    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.
    Last edited by Jacques1; August 2nd, 2013 at 08:07 AM.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    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".
  16. #9
  17. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    158
    Rep Power
    98
    Does Windows XP support TLS 1.2? 1.1?

    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.
  18. #10
  19. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by WrinkledCheese
    Does Windows XP support TLS 1.2? 1.1?
    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.

    You should rather spend this time on hardening the server.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    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".
  20. #11
  21. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    158
    Rep Power
    98
    Originally Posted by Jacques1
    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.
    Windows XP is still officially updated for another year.

    Originally Posted by Jaques1
    It (probably) doesn't reduce security,
    Oh, is TLS vulnerable to it's payload?

    Originally Posted by Jaques1
    but it doesn't add any relevant security either.
    Some people think it does, I actually found a jQuery plugin doing a similar thing.
    http://www.jcryption.org

    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.

    Originally Posted by Jaques1
    You should rather spend this time on hardening the server.
    It's Microsoft Windows Server...wait, you mean Microsoft products aren't military hardened impregnable Operating Systems? Are you goading me?

    ...I'm just joshing you, hardening is done. We're replacing the current software.

    Comments on this post

    • Jacques1 disagrees : *sigh*
  22. #12
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    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.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    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".
  24. #13
  25. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    158
    Rep Power
    98
    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.
    http://ocw.mit.edu/courses/electrica...y-spring-2003/

    Originally Posted by Jacques1
    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.
    Last edited by WrinkledCheese; August 2nd, 2013 at 08:43 PM.
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2009
    Posts
    191
    Rep Power
    50
    I've noticed a pattern on the Security and Cryptography forum, that plays out from time to time:

    Step A - Person ignorant about information security starts a thread that requests help.

    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 D - Kind folks continue efforts at education and correction, with surprising (but naturally, diminishing) patience.

    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.

    PS A possibly useful link for those open to learning: Javascript Cryptography Considered Harmful

    PPS Is "elitest" is a word in English?

    Comments on this post

    • salem agrees
    • AstroTux agrees
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2009
    Posts
    191
    Rep Power
    50

    Java SecureRandom class contains multiple severe vulnerabilities ...


    ... on Android platforms. Not necessarily applicable to the original post, but still maybe of interest:

    Android Key Rotation

    This kind of failure might happen with any language, on any platform. It is yet another example of how easy it is to get security wrong, even when everybody is trying to do it right.

    PS Reportedly, this is not merely a theoretical weakness, but has already been exploited to steal several thousand dollars worth of bitcoins.

    Comments on this post

    • salem agrees : excellent link
    Last edited by mah$us; August 12th, 2013 at 11:51 AM. Reason: added postscript
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo