There's an upside to the terrible security: no fingers have to be chopped to gain access.
The Tapplock IoT padlock has multiple security vulnerabilities
81–90 of 102 posts
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#82Earlier quoted context omitted.
They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.
> and programmed by programmers Not in my experience. But it's obviously not the same everywhere.
Maybe in garage projects, but there it can as well be in the opposite way. Would be really surprised to see it mixed in a corporate setup or with even smaller design contractors.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#83Earlier quoted context omitted.
Allowing HTTP is not insecure; if someone can intercept the connection, they can do so even if you don't have HTTP enabled.
Hmm? What could they intercept if you only have HTTPS (with properly checked valid certificates) other than the (useless to the attacker) encrypted data? Preventing that kind of thing is the whole point of SSL. If you enable communication without SSL it's not prevented, so it's less secure.
I'm saying that if the client tries to connect to HTTP/80 and the attacker has interception abilities, it doesn't matter if the legitimate server has that port closed, because the request will never get there.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#84The article recommends: > Don’t allow plain HTTP any more. Make sure your servers insist upon HTTPS connections, and update your client software to use HTTPS exclusively. Does this mean I should turn off HTTP completely? Right now, I redirect any incoming HTTP requests to HTTPS. Is this considered insecure?
Does this mean I should turn off HTTP completely?
The reason is, if you're using any type of hosting that shares IP addresses - Cloudflare, S3, Cloudfront - then you can't close the HTTP port as it's needed for other sites hosted on the same IP.
Getting your domain added to the HSTS preload list is a more conventional way of reducing HTTP traffic.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#85Earlier quoted context omitted.
Hmm? What could they intercept if you only have HTTPS (with properly checked valid certificates) other than the (useless to the attacker) encrypted data? Preventing that kind of thing is the whole point of SSL. If you enable communication without SSL it's not prevented, so it's less secure.
I'm saying that if the client tries to connect to HTTP/80 and the attacker has interception abilities, it doesn't matter if the legitimate server has that port closed, because the request will never get there.
Ah. Sure. But if the server doesn't listen on port 80 and you document this fact, clients won't regularly attempt to connect on port 80 (since they know it can't work).
I guess this applies more to non-browser client software than to people typing URLs in their browser address field, though.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#86Earlier quoted context omitted.
Hmm? What could they intercept if you only have HTTPS (with properly checked valid certificates) other than the (useless to the attacker) encrypted data? Preventing that kind of thing is the whole point of SSL. If you enable communication without SSL it's not prevented, so it's less secure.
I'm saying that if the client tries to connect to HTTP/80 and the attacker has interception abilities, it doesn't matter if the legitimate server has that port closed, because the request will never get there.
If it's an API, disabling HTTP reduces the risk someone will mistakenly code a client that uses HTTP, not notice their mistake, and later users of that client will get MITMed.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#87> Web programmer? Don’t make account IDs easy to guess. In an otherwise secure system, account numbers that go 1,2,3… shouldn’t be a problem, but why make it easy? Is that the best advice to web programmers they can give based on this story? That's the "obscurity" part in the security by obscurity scheme. If you've got your security otherwise nailed down fine, some obscurity on the top doesn't hurt: security-in-depth…
> Your authentication state is not "logged in", it's "logged in as user X". So the code that decides whether a client can see a specific page can and should (!) depend on what specifically you're authenticated as. "the code that decides whether a client can see a specific page" should not care about authentication, this is authorization issue. I see these things conflated too often. Identification, Authentication and…
Have you looked at recent at auth tutorials for NodeJS and related frameworks?
You (a potential beginner) have to basically implement everything yourself or use some 3rd party service. There just aren't any good libraries available.
I once tried some random framework I found where the example auth project that they provided had exactly the problem you described.
You could log in and then do everything if you called the api endpoints manually... Deleting and editing other users profiles? No problem.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#88Earlier quoted context omitted.
While EEs are part to blame, the other half is just graduated (or "bootcamp graduated" - let's put it this way) developers that know all the node.js shortcuts but don't know about the fundamentals of internet security.
Not sure we can blame bootcamps - I learned nothing about internet security in my software engineering college course.
But you probably knew that is was something to consider. And weren't told that you are basically a full fledged developer after a 3 month web dev course and after reading "cracking the coding interview". The Dunning–Kruger effect is heavily at work there.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#89> You could easily sniff out account IDs because Tapplock was too lazy to use HTTPS. SSL benefits are generally over-hyped IMO and might give a false sense of being 'Secure' as in this article where such an obviously flawed system receives "use SSL" as one of two recommendations. The idea that unencrypted traffic allows any hacker to easily sniff it is wrong and misleading. The eavesdropper needs to be "close": In th…
Almost all flaws are "not that serious" on their own, because people aren't generally _that_ dumb. "You can find out somebody's account ID" isn't that big a problem in the presence of other decent mitigations. Without those mitigations, of which HTTPS is one to prevent request spoofing, everything is terrible.
I agree, the account ID is a complete non-issue as long as each endpoint limits results to the account ID associated with the credentials.
Re: The Tapplock IoT padlock has multiple security vulnerabilities
#90Earlier quoted context omitted.
Sometimes I wonder how technology can work, when so many people working in the field are unable to grasp the basic concepts of it
Either the competent pulls way more than their weight, or luck.
Also the really bad stuff sometimes dies under its own weight. Natural selection occasionally works.