My comment had nothing to do with Bluetooth vs. USB comparison. I only said Bluetooth is a transport layer and claiming it’s “notoriously bad security” is not all that correct since most of the security parts come on top of it. So in many ways Bluetooth is quite similar to TCP, at least from point of communication. From the software point of view, both with Bluetooth and TCP, you create a socket then send and receive data through it. Literally the same interface. Protecting data that goes through either method is meant to be done at that point be it with encryption, identity verification, whatever.
Same thing applies to USB, but being physical it has added benefit of having to connect to it but that opens whole set of new potential issues. So it’s easier to physically protect it, but should that protection fail, you might end up in even more trouble.
That then in turn complicates things and requires maintenance people to be educated, etc. It’s possible to do authentication and handshakes properly without complicating matters. It just wasn’t done.
It does not complicate things in a way that makes things less secure than using Bluetooth 4.0 or earlier.
USB is way safer.
It’s amusing that you won’t just give up and admit that the blanket statement is 100% accurate. But you do you; just remind me not to use any services that you’re on the opsec team for.
Am just telling you there are ways to do security properly and make it good, be it Bluetooth, WIFI, GSM, LAN or USB. There’s no such thing as blanket 100% correct statements. I distinctly remember security issues with USB when protocol allowed DMA access which was used to leak all kinds of important data. Luckily it was patch fast, but that is the doing security properly part. There’s nothing completely secure in this world.
My comment had nothing to do with Bluetooth vs. USB comparison. I only said Bluetooth is a transport layer and claiming it’s “notoriously bad security” is not all that correct since most of the security parts come on top of it. So in many ways Bluetooth is quite similar to TCP, at least from point of communication. From the software point of view, both with Bluetooth and TCP, you create a socket then send and receive data through it. Literally the same interface. Protecting data that goes through either method is meant to be done at that point be it with encryption, identity verification, whatever.
Same thing applies to USB, but being physical it has added benefit of having to connect to it but that opens whole set of new potential issues. So it’s easier to physically protect it, but should that protection fail, you might end up in even more trouble.
You can disable a USB port and require remote SSH to enable it.
USB is way safer.
You can disable Bluetooth and require remote SSH to enable it… 🙄
BTW, have you heard about BadUSB?
That then in turn complicates things and requires maintenance people to be educated, etc. It’s possible to do authentication and handshakes properly without complicating matters. It just wasn’t done.
It does not complicate things in a way that makes things less secure than using Bluetooth 4.0 or earlier.
USB is way safer.
It’s amusing that you won’t just give up and admit that the blanket statement is 100% accurate. But you do you; just remind me not to use any services that you’re on the opsec team for.
Am just telling you there are ways to do security properly and make it good, be it Bluetooth, WIFI, GSM, LAN or USB. There’s no such thing as blanket 100% correct statements. I distinctly remember security issues with USB when protocol allowed DMA access which was used to leak all kinds of important data. Luckily it was patch fast, but that is the doing security properly part. There’s nothing completely secure in this world.
And you still won’t agree to the simple and obvious truth that USB is way safer than Bluetooth 4.0 or earlier. Nice.
You do you.
Why would I agree to something that’s not correct. You just pulled that out of your ass and claiming it’s true.
k