Protecting from data ciphers

[Richard_Grant]

Data siphoning is becoming more common every day,

Data siphoning is when you intercept the data and sniff between a client and a host, also known as sniffing a connection. ( i am focusing on session hijack)

 

To protect clients I've decided to write an MD5 calculation function which changes a secure string (such as a password) to plain MD5

 

Then once the MD5_password reaches PHP i BCRYPT with cost 20 using password_hash

_

 

MD5 is not ideal at all and i would like to write a better encryption but i only know how to do MD5 for java script, but i really don't need that much security here.

the purpose is to not show sensitive information, that's going to be hashed on the server, during a data siphon attack.

_

 

Data siphoning can not be protected against on the host server, the siphoning happens on the clients side usually when they don't have a strong firewall or such.

 

 

What are some good techniques you would practice to protect from data siphoning?

 

 

 

Before added security i was able to siphon this: 

Username: Richard

Password: mypassword

 

After added security i was able to siphon this: 

Username: 6ae199a93c381bf6d5de27491139d3f9

Password: 5f4dcc3b5aa765d61d8327deb882cf99

 

 

Now the only vulnerability between the client and server is if the hacker dns hacks the client which could redirect them to a website that looks like mine with the same EXACT url. which i can't help.

 

The real username can be retrieved in a session on login.

 

 

The real username and password can be found if a hacker injects js to remove the MD5 function, so if you know how to detect JavaScript injection i would like to know that as well.

 

 

______

Pretty much it looks like this..

 

Form -> Send md5(username) & md5(password) -> Server check if match in datbase -> If so login.

                                                                                ^ cypher                                                               ^cypher (session)

Edited September 12, 2014 by Richard_Grant

[requinix]

Data ciphering is when you intercept the data and sniff between a client and a host, also known as sniffing a connection.

Data "ciphering"? Maybe you mean data siphoning? Honestly, I stopped reading at that point.

[Richard_Grant]

Data "ciphering"? Maybe you mean data siphoning? Honestly, I stopped reading at that point.

Yes, now go back and reread it. The terminology is irrelevant

[Richard_Grant]

I just realized that hashing the username is pointless because the session will just get the right username after.

_ so instead _

 

Im not going to store the username in a session like i usually do,

Im going to store the ID of the user and make the db get the information when needed.

[Jacques1]

Never invent your own security protocol. As a layman (which we all are), your chance of success is exactly zero. And even if you were a security expert, designing protocols is a matter of many years and extensive peer reviews. It's not something you do on your own in 5 minutes.

 

The solution to your problem is TLS/SSL. This reliably prevents people from sniffing or manipulating the network traffic. You find it too heavy for your purposes? Well, there's a reason why it's heavy. If there was a shortcut, trust me, we'd already use it.

 

So for an actual website, any custom protocol is out of the question. If you're doing this purely for educational purposes, the whole idea is still heavily flawed:

 

First of all, it's not even clear what you're trying to protect. The MD5 hash is the password to your application, which means you still transmit it as plaintext. Anybody who intercepts the hash can log in as that user. The only theoretical benefit is that the attacker doesn't immediately see the original input, so if the client reuses the same password on a different site (which of course you should never do), then the account on that other site may survive a bit longer. But for your own site, there's absolutely no benefit whatsoever.

 

Then of course there's a conceptual error: As you've already realized, anybody who is able to manipulate the network traffic might as well remove all the fancy JavaScript code and grab the original user input. There's no solution to this. You simply cannot create trust within an entirely untrusted environment. You need something to start with. In the case of TLS, that's what certificates are for.

 

So at best, you get protection against passive attackers which only listen and never manipulate the traffic. But since we cannot choose our attackers, this isn't very useful.

 

Last but not least, JavaScript is not always available. For example, many people turn it off for security reasons. What now? Does it mean the plaintext password gets sent around? Does the entire site cease to function?

 

Note that those are not suggestions for fixing the protocol. It cannot be fixed. The only option for a production website is TLS.

[ginerjm]

...  The terminology is irrelevant

 

Really??  In English as well as PHP, JS, C+, Pascal, Fortran, Cobol, CICS, and any other language - spoken or written - I find the terminology to be very important as well as relevant.

 

A silly statement. 

[lawless]

Webapplications are generally unsafe, unless you make them safe. The only way to do this is the following:

 

(picture attached)

 

Only if you follow these steps, your webapplication may be secure for the most of the time. It is much more easy to secure an piece of software that is running constantly (locally installed software) instead of an application which runs once and then dies. I see this aspect as an main component for unsecure websites.

 

Then again million of websites are not using SSL, because, well, nothing much happens. Even if you lose a few sets of data to an attacker, nothing much will be lost. Reset the password, disable the account until the user verified his account by email and you're done.

 

My bank has to use SSL, because if they don't I will have no money. This site or other communities do not need that harsh security measurements, just because there is no valuable data to lose (in terms of money speaking).

 

A few obstacles in the way for the attacker, like checking for special characters, control characters and encoding / decoding, email-verification and so on are quite good enough for those kind of sites. You won't need to buy the right to use an SSL certificate, only if you are in need of it (running an webshop, handling money transactions and so on).

 

By changing the user's input on the client side you do not know what really happens. Maybe there is an attacker using encrypted "test" user logins, while you just accept them (because they are encrypted, that's why my javascript did work - i do not need to worry about it).

 

Javascript is nice for handling client requests, loading parts of your website and having nice (or annoying) graphical effects. But then again for security: do not use.

 

 

 

 

Let's say your application is locally installed with an encryption system. You do not want to give the full system to your user. The client shall request an encryption method after authentification (maybe paired with an auth key), then encrypt the data with that particular instruction, send it using an secure protocol and only receive the answer after he is officially validated as user X. This compaired with regular re-checks of his authentification and validation thereof grants great security. Something that is missing (except when using SSL) for webapplications written in PHP, ASP and other languages that run the same way PHP does.

 

[Richard_Grant]

Never invent your own security protocol. As a layman (which we all are), your chance of success is exactly zero. And even if you were a security expert, designing protocols is a matter of many years and extensive peer reviews. It's not something you do on your own in 5 minutes.

 

The solution to your problem is TLS/SSL. This reliably prevents people from sniffing or manipulating the network traffic. You find it too heavy for your purposes? Well, there's a reason why it's heavy. If there was a shortcut, trust me, we'd already use it.

 

So for an actual website, any custom protocol is out of the question. If you're doing this purely for educational purposes, the whole idea is still heavily flawed:

 

First of all, it's not even clear what you're trying to protect. The MD5 hash is the password to your application, which means you still transmit it as plaintext. Anybody who intercepts the hash can log in as that user. The only theoretical benefit is that the attacker doesn't immediately see the original input, so if the client reuses the same password on a different site (which of course you should never do), then the account on that other site may survive a bit longer. But for your own site, there's absolutely no benefit whatsoever.

 

Then of course there's a conceptual error: As you've already realized, anybody who is able to manipulate the network traffic might as well remove all the fancy JavaScript code and grab the original user input. There's no solution to this. You simply cannot create trust within an entirely untrusted environment. You need something to start with. In the case of TLS, that's what certificates are for.

 

So at best, you get protection against passive attackers which only listen and never manipulate the traffic. But since we cannot choose our attackers, this isn't very useful.

 

Last but not least, JavaScript is not always available. For example, many people turn it off for security reasons. What now? Does it mean the plaintext password gets sent around? Does the entire site cease to function?

 

Note that those are not suggestions for fixing the protocol. It cannot be fixed. The only option for a production website is TLS.

 

I stopped reading this at 

 

 

The solution to your problem is TLS/SSL

 

All log in and registration scripts should be in SSL, Which mine are. The data can still be grabbed from https.

[Richard_Grant]

#closed

[kicken]

The data can still be grabbed from https.

Not by a third-party in the middle, which is what your whole post is about.

[Jacques1]

Richard, why did you even ask when you appearently think that we have no idea what we're talking about?

 

I took your idea very seriously and told you exactly what I think is wrong and what you should do instead. If you won't even read that, well, what's the whole point? Just do whatever you want to do and save everybody the time of writing useless replies.

 

I'll happily explain why I think that TLS solves your problem, and I'll happily read your explanations for why you think that TLS is not the solution. But if you just reject any criticism and “close” the thread, there's really no basis for a discussion.

[gizmola]

Richard,

   I am not sure I understand either your original point or your train of thought.  To quote you:

 

Data siphoning is when you intercept the data and sniff between a client and a host, also known as sniffing a connection.

 

 

I agree that sniffing is a potential problem.  It is far less of a potential problem than people think however.  In order to sniff someone's packets, you need to be able to technically intercept their packets.  With the advent of high speed switching, there are far fewer places for people to sniff -- although the pervasive use of wifi hotspots are a problem.

 

What I don't understand is your assertion that the use of TLS/SSL doesn't secure your communication, when in fact it does --- via strong encryption.

 

If there's some misunderstanding here, then you should probably respond with the specifics. 

[Jacques1]

I agree that sniffing is a potential problem.  It is far less of a potential problem than people think however.

 

It's actually a much bigger problem than most people realize. And, no, I'm not talking about hotspots or the infamous “internet café” scenario. There are many other legitimate ways to access the internet, be it a VPN, Tor or a proxy. And while it may be reasonable to trust your ISP, it's hardly reasonable to blindly trust a Tor exit node or a small VPN provider.

 

Network sniffing is a very real threat, not just a horror story for network administrators. Maybe it's less of a problem for you, but that doesn't mean everybody else is in the same situation. So I'd be careful with such statements.

[Richard_Grant]

Richard,

   I am not sure I understand either your original point or your train of thought.  To quote you:

 

 

I agree that sniffing is a potential problem.  It is far less of a potential problem than people think however.  In order to sniff someone's packets, you need to be able to technically intercept their packets.  With the advent of high speed switching, there are far fewer places for people to sniff -- although the pervasive use of wifi hotspots are a problem.

 

What I don't understand is your assertion that the use of TLS/SSL doesn't secure your communication, when in fact it does --- via strong encryption.

 

If there's some misunderstanding here, then you should probably respond with the specifics. 

 

Because you can force when the user goes to https://www.mysite... to go to http://www.mysite

[Jacques1]

No, you cannot. That's the whole point of HTTPS: You either get a secure connection, or you don't get any connection at all.

 

Do you understand how HTTPS works unter the hood? As soon as you enter “https://” into the URL bar, your browser starts the TLS handshake. At that point, the best an attacker can do is make the connection fail. But they cannot forge the request or the response. Again, that's the whole point of HTTPS.

 

Maybe you're confusing this with “sslstrip”-like attacks where an attacker replaces all HTTPS links within an HTTP response. Yes, that's possible. But nobody ever claimed that plain HTTP provides security. It doesn't. If you want security, you must use HTTPS on the entire site.

Edited September 13, 2014 by Jacques1

[jazzman1]

 

 It is far less of a potential problem than people think however.

 

Unfortunately, Jacques is right. We're all under massively surveillance these days by our ISPs, telecommunications companies and the government. This article talks about Canadian surveillance, but it would be apply to Americans and Europeans as well.

[gizmola]

Network sniffing is a very real threat, not just a horror story for network administrators. Maybe it's less of a problem for you, but that doesn't mean everybody else is in the same situation. So I'd be careful with such statements.

 

 

I don't think it helps people to make hyperbolic statements about sniffing, and raise the level of paranoia without a healthy understanding of exactly how and when your packets might be intercepted.  Most people that hook up to their ISP will find that they can't sniff anyone's traffic.  

 

Now if we're talking about a cloud server, or something like that, then I would agree that it's a much more likely scenario.  I'd actually encourage people to try out some of the common sniffing packages, as they have great utility when debugging network applications.

 

Just to be clear, I'm not trying to say that people shouldn't implement TLS, or use VPN's or anything like that.   But by the same token, they need to understand some networking basics and ideally, have explored the tools that facilitate the problem in the first place, so that they're clear under what circumstances they might be exposed.  

[Jacques1]

I'm not sure if you've understood my point. A proxy or WLAN hotspot doesn't need any low-level network tricks to intercept the traffic. It's a very simple scenario which anybody can understand: All traffic flows through one intermediary. And if you don't protect yourself, then this intermediary is free to sniff or manipulate the incoming or outgoing data.

 

This simple example is enough to explain the necessity of HTTPS. You don't need to give people a 1000-pages book about TCP/IP (although education is never wrong, of course).

 

I understand that you like to play devil's advocate and make provocative statements to keep the discussion going. But when you look at reality, I think the situation is a bit different.

 

So people are paranoid and vastly exaggerate the risk of network sniffing? It's rather the opposite:

• While there may be a vague fear of state-level surveillance, you rarely find users who actively protect themselves against concrete risks (public hotspots etc.).
• When talking about HTTPS, a common reaction is: “Only large banks need that!” In fact, some of your fellow “gurus” spend a lot of time trying to convince users of that.
• I still see people use FTP to access their precious servers.
• Good luck finding somebody who knows how to encrypt and decrypt e-mails with PGP/GPG.

Where is this terrible paranoia you're fighting against? Do you really think our problem is too much security?

[anderson_catchme]

I'm sure Jacques1 is correct, but arguing on the internet is stupid and this should be closed.