Live data from Hacker News

The Tapplock IoT padlock has multiple security vulnerabilities

nakedsecurity.sophos.com

21–30 of 102 posts

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#22

The 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?

It's insecure because whoever intercepts the unencrypted HTTP request could redirect it anywhere, i.e. to their evil site instead of your secure site.

But if you set the Strict-Transport-Security header[1] that will tell the client to go directly to HTTPS in the future, without needing to be redirected, so future requests will be secure as long as the initial redirect request is not intercepted.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#23

Utterly horrifying, but ultimately irrelevant. No lock of this size is meant to be anything other than inconvenient to open. Angle grinders are cheap, and more easily wielded than HTTP request crafting.

however there are cases where an attacker doesn't want to arouse suspicion, and Angle grinders are kind of noticable.

This would allow for an attack where the lock appears to be operating successfully, but someone has unauthorised access.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#25

> 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…

Of course your authentication scheme should be secure even if someone knows how the user IDs are generated. With that said it might be a good idea to exposing something like GUIDs to the user anyways, for example if you are worried about a competitor getting an exact count of registered users / products / orders (which the competitor would get by themselves doing the action and observing the created ID).

https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca...

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#26

Utterly horrifying, but ultimately irrelevant. No lock of this size is meant to be anything other than inconvenient to open. Angle grinders are cheap, and more easily wielded than HTTP request crafting.

however there are cases where an attacker doesn't want to arouse suspicion, and Angle grinders are kind of noticable. This would allow for an attack where the lock appears to be operating successfully, but someone has unauthorised access.

For this reason the scariest bit is the ability to access account information via their online systems - sounds like a map of locks that aren't locks.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#27
In a different market, with a different product, this could have been a funny success story 10 years later.

Something like:

> "when we launched, our [thing] was totally insecure and we had just thrown together a bunch of spaghetti code over nights and weekends- anything that would ship. Then when we hit it big we started investing in the process and now our [thing] is the best, most secure one on the market"

Too bad in this case [thing] is a lock, where proper security is it's primary, and single reason for existing. There's no 10 years later for this one.

Post reply on HN