I've just noticed Codetaff doesn't use HTTPS. How secure is HTTP? Considering banking details etc. are on there, is it safe?
Attachment 6575
Printable View
I've just noticed Codetaff doesn't use HTTPS. How secure is HTTP? Considering banking details etc. are on there, is it safe?
Attachment 6575
There's a number of aff programs who STILL have not moved to SSL. Any login that's not SSL (https), the login data could be intercepted - it's sent over the net as plain text. Same goes for any personal/banking data etc.
SSL (https) data in encrypted.
Whereas http is not.
Reiterating, http is transmitted (sent) in plain text format to the server, and visa versa. Hence, http is not secure!
SSL is overhyped; for websites at least.
The only security it provides is for data transmission from website to the server. If I wanted to steal that transmission; I'd sit outside the data center that houses thousands of servers and then try to brush it out. Only complex hacking is done this way; for example, the ones we see from the NSA, the Russian government and the greatest looking guy in the world: Mr. Kim Jong un. Such attempts of housebreaking are generic and used for retrospective information retrieval.
There are higher chances of larceny by data center employees, who willfully sell out client profiles to the highest bidder than remote hacking; as it requires enormous resources that only the governments and organized crime syndicates have.
Users are vulnerable when they use an unencrypted internet connection
A website can have an SSL installation, yet the client profiles can be stolen; if one's connection from the browser to the website is insecure. SSL only encrypts data movement from the website to the server. This means that if you were the target, any person running wireshark-type data-packet sniffing software would be able to suck out the user and password details you send over to an SSL site.
The solution to that is a VPN connection, that encrypts your connection to the data centers. People who don't even know what a VPN is; are in the majority.
More security is required on POSs, where credit card data is sent out to the processor. If it's insecure then it can be smelled out by somebody sitting in a car, in the parking area. This is a huge problem in the U.S., and most credit card thefts happen this way.
Many large U.S. stores don't secure credit card processing over the internet.
While I agree the chances of someone specifically intercepting a unsecured http data send, is unlikely, the OP specially asked "how secure is HTTP?". In which case, the correct answer is, it's not secure.Quote:
Originally Posted by Malikbhai
Not at all secure, on any level, information is being sent unencrypted to and from the server.Quote:
Originally Posted by Scampi
Point of order gents - computer nerd speaking :
Because we are talking about proper websites like Income Access or NetRefer- it's unlikely that the actual password is being sent anywhere.
This would be extremely bad practice - and I'm pretty sure that you guys did actually guess that in the 15-20 years of the internet prior to https being widespread that passwords were not being compromised.
:eyebrow:
What is most likely to be sent from the browser is a SHA-256 HASH of the password and other elements in the message to the server.
The server then compares this value against a HASH of the locally stored password using a secure process.
This is the same way banks send PIN data from ATMs and EFT-POS all across the planet using basic x.25 protocols (the message is never encrypted) and don't have to worry about the integrity of the systems or data. Sensitive PIN information is never exposed in transit only a calculated HASH.
Another powerful real-world example of how encryption algos can help business. (like Crypto-currency)
--------------
NB :
A HASH is a computational encryption of data to get an 8 or 16 byte result - it takes the pin or password, and usually 2-3 items of other known data - including one piece of changing data (like milliseconds or sequence number) and gets a result that is very variable but cryptographically calculable and secure.
eg. Here is a basic example.
Let's take a password example and use username Albert and password Einstein DONE AT 10:17AM ON 20-03-2018.
The crpytographic function will take all three elements and convert them to hexidecimal equivalents and combine them in an extremely clever and complicated way that makes it extremely hard to crack
0000ALBERT
00EINSTEIN
1017436435
----------------
???????????? = HASH
It's impossible to reverse engineer this HASH back to the original password - as all the elements effect the HASH - so intercepting the HASH is useless. This means that PINS (and PASSWORDS) are transmitted security over unencrypted protocols.
-------------------------------
TL : DR; ?
In summary, in proper commercial systems the password is NEVER sent out of the browser at all.
Cryptography sends a clever HASH that means password data is secure whether it's http or https;
Now a days MD5 hashes or any other hashes for that matter are pre computed for all possible strings and stored for easy access. Though in theory MD5 is not reversible but using such databases you may find out which text resulted in a particular hash value.Quote:
Because we are talking about proper websites like Income Access or NetRefer- it's unlikely that the actual password is being sent anywhere.
This would be extremely bad practice - and I'm pretty sure that you guys did actually guess that in the 15-20 years of the internet prior to https being widespread that passwords were not being compromised.
Salting the hashes can add in extra security layer; which makes breaking even harder; if not impossible.
Most hackings that have a commercial value attached to it aren't the result of sophistication; but simple social engineering done on the employees of the victim company.
A successful heist is done through the effective use of human emotions; not scripts.
Can't speak for MD5 - but SHA-256 still gives good protection.Quote:
Originally Posted by Malikbhai
Basically - to do all the HASH calculations for the unknown piece of data (password or PIN) would take billions and billions of years - at 1 million hashes per second it would take
12,700,000,000,000,000,000,000,000,000,000,000,000 ,000,000,000,000,000,000,000,000,000,000,000,000,0 00,000,000,000,000 years to test all possibilities. (past the expected time of human life on earth).
And, there would be around 36^64 / 2^256 or 34,600,000,000,000,000,000,000 collisions found.
(These false positives where data matches the hash but isn't the correct value)
This stackoverflow answer explains it in detail :
https://stackoverflow.com/questions/...-a-sha256-hash
I'm aware of SHA-256. And yes, the latest cryptology adds another near-impenetrable firewall to an already decent packet transmission protocols.Quote:
Originally Posted by TheGooner
But eventually it jots down to one thing: is user data hackable or not?
Technically, perhaps not. However, like I said above; most financially lucrative breaches happen by someone sitting in North Korea making up a fake relationship with a forever-alone IT head who has access to client profiles - as an example.
Encryption technology is like wearing thick jackets in a cold winter; but this is not a guarantee one wouldn't get the flu. People wear the protective clothing in winters and still get the seasonal flu.
Companies need to be careful about who they are employing to fight against data breaches, than being pedantic about programming.
I'll park the North Korean diatribe ..
Although I'd suggest Russia, China, USA and Israel are probably far more active than the technically inferior NK state.
Glad we agree that http vs https is not a big issue for passwords with commercial systems.
Israeli contribution is far more prominent.Quote:
Originally Posted by TheGooner
But, yes. OK.
Not real sure how many websites are authenticating passwords on the public IP, instead of a private IP
Please do not try and think the database servers are "localhost"
So, sitting outside the data center does nothing really, unless you are already sitting on a compromised server inside, and if so has little to do with browser traffic.
Rick
Universal4
Watchoo talking bout Willis?Quote:
Originally Posted by Malikbhai
The website is on the server. It doesn't live in your browser. SSL encrypts the transmission of data between the client computer (i.e. your web browser) and the website's server, which may be 20 hops away across the internet. Among other things SSL protects your plain text passwords from being intercepted anywhere along those 20 hops along the way. That's it. If the server's private key is stolen then sure you could have a specific, targeted man in the middle attack. But no SSL means any server hop along the way can steal your data.
If a website is not using SSL then your password could be sniffed or captured. Sure they might be client side hashing the password first as TheGooner mentioned, but I think that is a mighty generous assumption to make as I have personally found more than a handful of casinos transmitting logins and passwords in plain text. RealDealBet was one I can remember not too long ago, and to their credit they fixed it when I pointed it out to them. Even if they are client side hashing first, if you're using a common word or you have reused your password from another site that has been breached, your hash may already be in a rainbow table somewhere already which means you are owned.
On that point, I tested out that CodeTaff site and posted a test login. I don't have an account there but this is the data my browser posted. It is clearly not being encrypted client side before posting.
Most casinos and poker sites have caught on and are using SSL these days. It is rare to find one that isn't. But affiliate programs are a different story and there are many that don't encrypt, which in this day and age is borderline criminal.Code:ReturnUrl=&__RequestVerificationToken=MHwwSjqjfOoSOua0IZ0tBYgK_ZqbA3qrq2b161M3K2Prb9j1rw97CvAX18QLoaQrJEx4gXtZblgNF8jVmm129ubgxVsmJA9W8142rLVIlMQ1&UserName=myusername&Password=testing&RememberMe=false
Quote:
UserName=myusername&Password=testing
Yes- I would expect the Password to be looking like Password=MHwwSjqjfOoSOua0IZ0tBYgK_ZqbA3qrq2b161M3K2Prb9j1rw 97CvAX1 if they were using ecryption or hashing or anything else - there is absolutely no need to send the password in clear text.
