Computer security bullshit

[IanMac]

Seems to me that computer security is another area with plenty BS.

'Internet security suite' packages which provide no more protection than standard AV software but cost three times as much and cause all kinds of trouble.

Claims that upgrading to Windows 10 will make your computer more secure, when the stats show that Windows 10 has had MORE security issues than Windows 7.

The notion that putting punctuation in passwords and changing passwords frequently would make things secure has persisted for many years. It has finally been busted with a mathematical proof that making the password even slightly longer makes more difference than punctuation. Yet, there are still loads of systems that enforce this. Once the BS has become folklore it's very hard to make it go away.

The current drive to make all websites use HTTPS smells suspiciously like BS too. The only thing that HTTPS protects against is man-in-the-middle attacks, yet that class of exploit hardly seems to figure at all in security stats. The vulns behind the really major hackings are all on the server or the client computer, where HTTPS offers NO protection at all. Fixing these real vulns is hard work for the programmers, which is why a BS solution is put forward instead.

Granted that HTTPS has a valid purpose in ensuring that sensitive data can't be viewed by data carriers. Applying it to all websites is ridiculous though, and will do nothing at all to mitigate the common security problems. It could be said that most BS operates on this principle of taking an item that has a valid use in some circumstances, and applying it in situations where it does not. Solar roadways are a case in point. The Batteriser is another, since switchmode step-up converters are a useful device in the right place. But, not here.

[f4eru]

Hello,

Some valid concerns !
The "antivirus" are mainly snake oil, and bad snake oil !

The current drive to make all websites use HTTPS smells suspiciously like BS too. The only thing that HTTPS protects against is man-in-the-middle attacks, yet that class of exploit hardly seems to figure at all in security stats

Nope. HTTPS also protects against eavesdroping under it's many many forms.
For example, if ever you use wifi, everybody nearby can receive your data, and the encryption and/or the passwords seem to be quite weak.
Also, a lot of state actors record absolutely every possible traffic, even for later decryption, so very strong transport encryption is necessary.

I recommend some 33c3 videos :
https://media.ccc.de/c/33c3

Look at "Security nightmares" ( available in English translation)

[Fungus]

Also, a lot of state actors record absolutely every possible traffic, even for later decryption, so very strong transport encryption is necessary.

How do you know the "state actors" aren't running the certificate authorities and passing out false certificates? Have you even checked the source code of your web browsers?

Back on topic: There's no way to debunk all that stuff because a large part of the problem is the users. It's not in Dave's field of expertise anyway, so.  Find a different blogger.

[wraper]

Only man in the middle, you say? Even if your PC is not infected, your router quiet likely is and could capture all of your passwords, for example. Not to say don't even dare using public wifi, your home wifi does not have much of protection either. Also infected router could redirect you to malicious website, without HTTPS you would not even have an idea about it.

[wraper]

For example youtube (if it was not encripted), someone steals your password which is the same as your gmail. Then steals all of your money from paypal account, even if it had a different password by restoring the password by using your email. Or steals, say, your eevblog password which was the same as on some other more important website. Most of the users are pretty clueless anyway. Also some governments are really interested about what you watch, and you may be prosecuted.

[slicendice]

HTTPS is very important, for the reasons it was stated here already.

About the Security suites...you need:

1. A good firewall that is configured properly
2. A good antivirus software that detects as much as possible with as little false positives as possible.

3. for really dumb web surfers, a lot of protection from malicious sites etc.

I find security suites very useful, because they have all security features in one product. But of course all this means the suite has to work properly on the OS you are using it on. On Windows 10 they don't work reliably.

On Windows 10 I only use Windows firewall and Windows Defender. No problems so far. I even use a third party (Paid) virus scanner to offline deep scan my whole system periodically, no found threats so far.

About passwords: For each added char in total available chars you increase the security a bit, but not much. But as stated before, adding one more character to the password length increases the security a lot.

And yes changing the password every now and then increases overall security in the long run, you never know when your password has been compromised/bruteforced. It is however more important to have different password for every site than changing the password all the time.

If one login gets compromised the rest will stay intact.

[madires]

Despite those internet security suites are meant to secure your PC they are also causing security problems. The latest one is Kaspersky screwing up checking SSL certs ( https://bugs.chromium.org/p/project-zero/issues/detail?id=978 ). And it should be clear that AV only protects you from known malware. You can do a lot without spending money when you know how malware commonly tries to enter your network or PC. For web browsers remove flash and java plugins, and use a no-script plugin to block java script (whitelist sites you need). And use a limited user account for web browsing, never an admin one.

[IanMac]

For example youtube (if it was not encripted), someone steals your password which is the same as your gmail. Then steals all of your money from paypal account, even if it had a different password by restoring the password by using your email.

No offence intended, but your reply underlines the very problem Dave talks of, that BS becomes so embedded in the public consciousness that it becomes hard to convince people of its incorrectness.

HTTPS encrypts the password at the browser, only for it to be automatically decrypted back to plaintext at the webserver.  The vast majority of password thefts occur when a server is compromised. The remainder happen when the user's computer acquires malware. You don't need to take my word on that, just check any site that collects intrusion stats.

Passwords should be hashed with a site-specific salt, which prevents them from being used on other sites even if they are stolen. Although, any kind of hash would be better than encryption. The hashed password is only vulnerable to malware in the browser. At all other times it is secure. 

By contrast, the HTTPS-encrypted (but unhashed) password is vulnerable at all of the places where theft most frequently occurs. That, and the stolen password will work on other sites where the same user/password combo have been used. 

Telling webmasters to use HTTPS to protect passwords is wrong advice. Like telling your GF she can't get pregnant if she takes a cold shower, wrong advice is dangerous because it leads to proper precautions being omitted.

Despite those internet security suites are meant to secure your PC they are also causing security problems. The latest one is Kaspersky screwing up checking SSL certs ( https://bugs.chromium.org/p/project-zero/issues/detail?id=978 ). And it should be clear that AV only protects you from known malware. You can do a lot without spending money when you know how malware commonly tries to enter your network or PC. For web browsers remove flash and java plugins, and use a no-script plugin to block java script (whitelist sites you need). And use a limited user account for web browsing, never an admin one.

+1 for that. 

[wraper]

LOL, so you are saying that HTTPS is unprotecting the password? Do you understand that encryption in the middle and how passwords are stored on the server are 2 separate things?

[IanMac]

LOL, so you are saying that HTTPS is unprotecting the password? Do you understand that encryption in the middle and how passwords are stored on the server are 2 separate things?

No, I said that HTTPS does not protect the password. Just as taking a cold shower does not prevent pregnancy. The problem lies in believing that it will.

They are not two separate things. The error is made at the client end, when the password is sent unhashed.

[slicendice]

And use a limited user account for web browsing, never an admin one.

I would like to add to that, NEVER use an Admin account for anything else than Administration. For this very reason there was a myth saying that Linux is more secure than Windows, when the real reason for Linux being more secure has only to do with how you are logged in while doing common stuff like browsing the web or running applications.

In Linux we never run as ROOT unless we absolutely must. In Windows on the other hand every default user added is an Admin, unless specifically changed in settings. This is a security problem, common for home users, while for companies with AD and proper security policies configured, this is no issue.

In administrated networks, there is only ONE master Admin with an insanely long and complex password which should be stored in a safe, the rest of the Admins are actually power users with higher privilege for specific tasks, and everything else has only access to specific apps, folders and tasks that has nothing to do with administration.

In these networks the master password is only retrieved from the safe when absolutely needed and it is changed after use and the new password is put back in the safe.

[wraper]

LOL, so you are saying that HTTPS is unprotecting the password? Do you understand that encryption in the middle and how passwords are stored on the server are 2 separate things?

No, I said that HTTPS does not protect the password. Just as taking a cold shower does not prevent pregnancy. The problem lies in believing that it will.

[slicendice]

LOL, so you are saying that HTTPS is unprotecting the password? Do you understand that encryption in the middle and how passwords are stored on the server are 2 separate things?

No, I said that HTTPS does not protect the password. Just as taking a cold shower does not prevent pregnancy. The problem lies in believing that it will.

 

[IanMac]

Seems like I need to spell this out.. The issue is that if a password is sent unhashed with HTTPS, then as soon as it arrives on the server it is automatically converted back to plaintext. If malware is resident on the server, say a CMS vuln having been exploited to inject a Trojan, then it is too late to apply protection because... GOTCHA! the malware has the password. 

If the password has been properly hashed before sending, that would not arise.

[iaeen]

The notion that putting punctuation in passwords and changing passwords frequently would make things secure has persisted for many years. It has finally been busted with a mathematical proof that making the password even slightly longer makes more difference than punctuation. Yet, there are still loads of systems that enforce this. Once the BS has become folklore it's very hard to make it go away.

Basic probability: for any given password length, you are less likely to guess the password if the character set is larger.

Sure, given an already reasonably large character set, adding an extra character to the set will probably do less than adding a character to the length of the password, but that does NOT prove that adding characters to the set is useless.

[wraper]

For example youtube (if it was not encripted), someone steals your password which is the same as your gmail. Then steals all of your money from paypal account, even if it had a different password by restoring the password by using your email.

No offence intended, but your reply underlines the very problem Dave talks of, that BS becomes so embedded in the public consciousness that it becomes hard to convince people of its incorrectness.

Just so you to understand. Youtube password is really the same as gmail, same account. And usually all it takes for the hacker to hack all of your stuff is like getting into your email and then reset the password on everything else. I always feel uneasy if need to login via non encrypted connection while using wifi in the airport. Your hashing on the client side won't protect you a tiny bit in this case.
EDIT: Attacker don't even need to steal your password. Session hijacking is enough.

[slicendice]

If the password has been properly hashed before sending, that would not arise.

So where do you think the hash and salt are located?

[iaeen]

Seems like I need to spell this out.. The issue is that if a password is sent unhashed with HTTPS, then as soon as it arrives on the server it is automatically converted back to plaintext. If malware is resident on the server, say a CMS vuln having been exploited to inject a Trojan, then it is too late to apply protection because... GOTCHA! the malware has the password. 

If the password has been properly hashed before sending, that would not arise.

The final hashing has to happen on the server, otherwise the hashed version is just your password.

To put it another way, under your security scheme, what is to stop the attacker from simply using the hashed password they captured to access the server?

[slicendice]

The notion that putting punctuation in passwords and changing passwords frequently would make things secure has persisted for many years. It has finally been busted with a mathematical proof that making the password even slightly longer makes more difference than punctuation. Yet, there are still loads of systems that enforce this. Once the BS has become folklore it's very hard to make it go away.

Basic probability: for any given password length, you are less likely to guess the password if the character set is larger.

Sure, given an already reasonably large character set, adding an extra character to the set will probably do less than adding a character to the length of the password, but that does NOT prove that adding characters to the set is useless.

 

[radar_macgyver]

Here's a quick primer: https://ssd.eff.org/en/module/what-encryption

Using https involves both encryption of in-flight data as well as validating the source using a certificate. Basic TCP/IP and http do not guarantee either. It's been recognized that the certificate infrastructure is, at best, a stop-gap solution that has numerous vulnerabilities, including interference from state actors. Also, it isn't too hard to become a root CA (look up WoSign for a good example of this going wrong), and the entire certificate signing infrastructure depends on trusting the root CAs. One proposed solution is DNSSEC, but there's a lot of change needed before it becomes widespread enough to make a difference.

One could argue that many 'calls for bullshit' are due to perceived financial gain on the part of the bullshitter (in this case, I assume that's the CAs). If that bothers you, use LetsEncrypt.

A benign example of how unsecured http can be used is injecting ads into http pages, as is commonly done at airport "free wifi" APs and shitty hotels. This is, at best, a nuisance, and at worst it can break websites. Far more sinister is being able to inject malicious javascript. While 'man-in-the-middle' sounds like something only a state actor or ISP can do, it's actually quite easy. DNS requests are handled over UDP, so whoever responds quickest to a DNS request 'wins'. I can camp out on your LAN (easy on public APs) and respond to DNS requests for, say, google.com by pointing to myself. I can then read your google cookie (and get the keys to that particular kingdom), inject javascript into the google.com page that I serve to you that can exploit flaws in your browser to grab passwords entered into fields, etc.  Also, note that I did not need your browser to send me a password (hashed, salted, spiced, whatever) to do any of this. None of this is possible after google switched to https.

Finally, without encryption, everything is up for grabs by law enforcement. You might say 'I did nothing wrong, I have nothing to worry about', while forgetting about false positives. Most of what law enforcement looks at is through pattern matching, which can get caught up so easily by the wrong keyword. EEVblog does not use https, so all it takes is for someone posting child porn (as happened recently) for everyone on the forum to come to the attention of law enforcement. I can be certain that some server at the NSA has now flagged me for posting this.

[slicendice]

Very good text there radar_macgyver! 

[IanMac]

To those posting retorts like 'and where do you think the salt is generated' or 'the hash is just your password' I suggest you go study how password hashing is done and why it is done that way, as you clearly do not understand the process.

@radar_macgyver -Nobody is saying that HTTPS shouldn't be used for sensitive data. That is beside the point.

To conflate that with what I said, is like saying that because the Batterizer is junk you should never use any SMPS. Non sequitur.

Though, I fail to see how HTTPS would prevent law enforcement from spotting illegal material on this forum. All law enforcement need to read the material is a HTTPS-capable browser. In fact, it is possible to robotically scrape HTTPS sites without even opening a browser. The standard PHP libs can do that for you.

In suggesting that HTTPS would prevent law enforcement from seeing the material, you have underlined the fundamental issue of BS.
A misapplication of (a perfectly valid) technology to a situation where it does nothing useful, but sounds like it ought to.  Until, that is, you think it through.

[wraper]

Non sequitur.

And I was wondering why this tread reminds me this

[wraper]

Though, I fail to see how HTTPS would prevent law enforcement from spotting illegal material on this forum. All law enforcement need to read the material is a HTTPS-capable browser.

It would prevent them seeing you are accessing that material, in the first place.

In fact, it is possible to robotically scrape HTTPS sites without even opening a browser. The standard PHP libs can do that for you.

BS, if that material is hidden from regular user or there is no open registration, there is no way to know that material is there. Unless they catch someone who tell them about that prohibited material. Or they find it on the confiscated computer.

To conflate that with what I said, is like saying that because the Batterizer is junk you should never use any SMPS. Non sequitur.

Indeed, you made a bold conclusion and then refuted it yourself 

[rs20]

Have you considered that the big, newsworthy hacks are all server/client based, but there's lots of undetected/unreported grassroots packet sniffing/MITMing going on on personal/university/company LANs? If there's some dodgy dude in the corner when I visit a LAN, isn't it quite reasonable for me to want all my web traffic to be over HTTPS, so that the precise content I'm receiving is private to me, and known to be exactly as the server sent (i.e. free of injected JS?). Sure, the actual host I'm talking to isn't private (DNS, and the resulting IP address of the host are a separate issue), but it's infinitely cheaper than operating a tunnel to a VPS somewhere.

Though, I fail to see how HTTPS would prevent law enforcement from spotting illegal material on this forum. All law enforcement need to read the material is a HTTPS-capable browser.

It would prevent them seeing you are accessing that material, in the first place.

This. It also hides what your username is -- if I sniff your connection over HTTP, I can tell that you're IanMac and you posted this message. If I sniff your connection over HTTPS, I can tell that you're accessing the forum something at www.eevblog.com, and by looking at the site, I can tell that someone, somewhere called "IanMac" posted this message, but how would I tie those two facts together? Obviously timing attacks remain an interesting way to figure out what's going on ("this connection created some traffic at the exact instant IanMac's message was posted"), but there's no harm in making the task considerably more difficult for the attacker.