ATS change to https

a reply to: ThatDamnDuckAgain

Your password was not stored in plaintext.

The password feature encrypted it on an algorithm and compared encrypted output to stored encrypted password. The vulnerability would be at your machine. Let’s say your password was 123456 and the encryption made it 654321 (simplest thing for demonstration), then it is only going to look for whatever outputs 654321.

Now plaintext isn’t really plain text either. Each character has a value (hexadecimal) and that value (after converting hex to binary) is transmitted. You can train yourself to decipher and read it. So a “man in the middle” attack (something on your machine or ours or routes traffic through it) could in theory read this. Your post is (converted) plain text, so they could just wait until it posts... your password would be received as 654321 (really it would look something like A7bceF1679BED46) which is meaningless unless they can decipher it back to what you originally typed or used a keylogger on your machine (as the easiest means and again your machine).

So what does the https do for us? It allows ATS to get through firewalls and other security programs that block “non-secure” sites. Is it needed? Not really. Does it help reach a wider audience? Yes it does.

a reply to: Ahabstar

Your password was not stored in plaintext.

The password feature encrypted it on an algorithm and compared encrypted output to stored encrypted password. The vulnerability would be at your machine. Let’s say your password was 123456 and the encryption made it 654321 (simplest thing for demonstration), then it is only going to look for whatever outputs 654321.

Yes this is what I tried to express. I read that it's common practice that when I type in my password to login, my browser does a one way encryption the same way it was done when I registered my account?

But the point is, even if my password is encrypted it's the string of letters that counts that is compared. With HTTP before that was vulnerable, right? So when someone at my internet provider feels like it, a unencrypted HTTP connection should still in theory provide the encrypted string that is sent to ATS to compare if I typed in the password correct.

The password itself might not be visible but the informational value is. So if someone at my ISP or someone that sit's in the middle of my communication can record this string all the person has to do is come up with modified request to the ATS computer, send the encrypted string of letters to ATS that will conclude "yes this is exact what I have stored".

So before, without HTTPS, even if the password was encrypted to be compared, it was useless because if someone would get ahold of the encrypthed password, it's enough.

If it's always sent in plaintext inside the packet stream, HTTPS or not, and ATS does the encryption itself so it can compare it to it's own encrypted information, then what I wrote isn't false.


So wich one of these scenarios was at work and is currently at work?

HTTP with server side password encryption
Me to ATS: I want to login; TDDA/pekingDuck
ATS server: I will take "pekingDuck" and do a one way encryption that results in "§§Ri05213ju052ujh035jh2j2t", I compared my stored password for you is "§§Ri05213ju052ujh035jh2j2t". Access granted.

HTTP with client side password encryption
Me to ATS: I want to login; TDDA/§§Ri05213ju052ujh035jh2j2t
ATS server: That's what I have too, access granted


The same for HTTPS but this time not everyone down the line can read it in plaintext. Now, what prevents anyone from the first two examples that can record the conversation in plaintext, to just come up with a faked login request that has all the above inside.

Your reply doesn't answer this since you overread that I brought up the exact example you used. I would appreciate it much if someone can jump in and tell me at what point I am wrong with the above. I don't have a lot of knowledge about programming but I am starting.

a reply to: Ahabstar

Does it help reach a wider audience? Yes it does.

That is probably the main if not the only reason...

There was this lady I referred to a site that was http. Her Browser made a warning and she straight up said that must be fake news.

a reply to: ThatDamnDuckAgain

I don’t know the technical workings for SSL (https) but you pretty much have http encryption explained there. There is of course a couple extra steps as the info is converted to hexadecimal and then to binary as all data transmitted is 1’s and 0’s.

Not to go into the entire history of cryptology but if you think of the basic Caesar Cypher A=13, then run those results through an A=5, and so on until you hit the level of encryption you want. You reverse that to get back to your original message. You may go some 200 layers in and back out and there will a codebook somewhere of what you do to decode it.

If you look at the old Numbers Stations on Shortwave Radio, they repeat the same series of numbers and supposedly there is a code book that tells you what number means what on each day. So while the repeating number set is identical every day, the meaning changes based on agreed upon codes. So far no one does that style of encryption online, well maybe in sterograms, but imagine if they did.

Then again, I’m amazed that the series of 1’s and 0’s knows when to be converted to a particular font like Helvetica or Dingbats or an animated.gif

originally posted by: Ahabstar
The password feature encrypted it on an algorithm and compared encrypted output to stored encrypted password. The vulnerability would be at your machine.

So how did a bunch of us get hacked last year? Happened multiple times.

a reply to: Ahabstar

Thank you for explaining. My question remains, before HTTP the password was accessible in one way or another to anyone in the middle or at the ISP.

It's becoming even better as I read into this. @ Augustus, have you used external wifi to browse ATS because anyone inside that network could capture this plaintext stuff and go with it.

And I only make a fuss about this because a while back there were some members making fun of me and others that had these worries. So in retrospective I won't trust these persons anymore, because they flat out lied or had been giving absolute incompetent security advices.

originally posted by: ThatDamnDuckAgain
@ Augustus, have you used external wifi to browse ATS because anyone inside that network could capture this plaintext stuff and go with it.

I was asked to not go into details by the Admins.

a reply to: AugustusMasonicus

Lots of ways it could have happened. Even brute force attacks will work eventually. The site itself is a hodgepodge of available and custom code. Some things have cracks. Some things are very locked down. And many, many things are quite above my pay grade so to speak.

While quite familiar with making and manipulating a FileMaker database, that doesn’t fully translate to other databases. Sort of like I cut my teeth on Atari Basic but could not do some things on a Commodore64 in Basic. Even the command line for loading from a cassette drive was different between the two.

Will a SSL certificate change those vulnerabilities? Nope. In fact, it is entirely possible that it introduced new ones that people have not figured out as of yet.

And it is still illegal to have a working CRAY because they can be used to decrypt complex encryption. Never mind that nearly every home computer can out perform a CRAY at the same task, breaking encryption...

a reply to: AugustusMasonicus

how did a bunch of us get hacked last year?

The same way as the year before, now you just happen to notice.

Or

you wouldn't eventually be working on an alibi?

originally posted by: AugustusMasonicus

originally posted by: Ahabstar
The password feature encrypted it on an algorithm and compared encrypted output to stored encrypted password. The vulnerability would be at your machine.

So how did a bunch of us get hacked last year? Happened multiple times.

Doesnt matter how the password is persisted, before ATS used ssl, 100% of everything transmitted from the client to ATS server was 100% in plain text. No need to have a compromised machine because this site has always been vulnerable at the transport layer.

Let's not even get into the lack of serverside validation.

a reply to: AugustusMasonicus
Yes I should have worded it different, I agree for security reasons. I checked if I can remove my post but it's to late and you quoted it.

a reply to: AScrubWhoDied

do I get that right?
its like before https everyone wit the skillset could mine the data, now only a handfull can?
not sure what is better....

a reply to: Terpene
I would not give a lot on my answer but as I understood it you need access to the internet's routers to pull it off.

Because in my former job I was responsible for monitoring the VPN server. I didn't configure it but I knew how to troubleshoot our hardware and to TCP dump on interfaces, hosts etc.

This was basically the same we talk about and in some occasions, if I wanted to, I could read some packets in plain text. With https. Because a workmate wired the certificate into the tool so I could dump around and learn stuff.

Normally this is only possible with http if I understand it. But I am not professional, I was just explained what I need to do and how I can achieve that. For that we used linux but I really just know a few commands like the vim or ifconfig, ping, nmap and such. Also tcpdump, that can also dump UDP I found out.



Add: For example I would SSH via VPN tunnel into a router at a power plant and when there was trouble like a broken sensor or third party hardware not routing corretly, I would dump the packets to see if the claims are valid. Like them saying they get no connection to their server or internet at all but I can see the response from their server to their IP, they were just dumb enough to tell us all the ports so I could change the iptables and we're good.

This would be the prime example because I would see all traffic from and to the device, could record it or deny etc. Because I sit in the middle, that's what ahabstar ment with man in the middle. I just don't know enough about how login works on websites but I know that these calls can be trapped and modified, as I saw similar ones.

That's why I asked for ATS but I now learned I really don't want to hear the answer and would get none. And that's good this way for safety.