71–80 of 102 posts
Earlier quoted context omitted.
IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.
They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.
Not in my experience. But it's obviously not the same everywhere.
Frankly, this all seems like quite a lock of fuss over nothing. Firstly, pad locks are generally very easy to just break open with a set of bolt cutters. Particularly, if you look at more secure traditional pad locks practically all of them share physical design features intended at minimizing the amount of the actual shackle that's accessible. So to be clear- the second you see the shape of that padlock you know tha…
Also, it costs $99. I'm pretty sure you could buy a fairly secure normal padlock for $99.
Earlier quoted context omitted.
IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.
That’s wrong. An engineer has a couple managers above. Product, project, platform manager. You name it. Engineer is just another blue collar worker nowadays. No decision making power. I was not allowed to save company $40k, they told that numbers shouldn’t interest me. If management says, we need no encryption and authentifition, it’s totally ok. I just print their emails with this statement for later.
Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
Silicon Valley prefers teams to have epic backstories, not experience. A first-year dropout from MIT and a Thiel fellow are much more likely to get funded than an engineer with a state uni BSc+25 years industry experience plus a former sales manager in the same industry.
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?
So it depends on your client population. If you've got general browsers hitting your site, I think HTTP-->HTTPS is a reasonable trade off and stops the poor experience of a user putting your site name into the browser bar and getting told there's no site there. If you control the client population, as in this case, there's no real need to allow HTTP at all, so I'd just disable it and have HTTPS only.
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…
I thought this was a blog post about the guy who simply unlocked the padlock using a GoPro mount ( https://www.youtube.com/watch?v=RxM55DNS9CE - the video is worth watching from the beginning) but this was more amusing than I was expecting. Nothing went right in the design of this padlock.
I wonder why the "message" field in the response says "API调用成功" ("API call succeeded", I think?) if this is a Canadian company. Did they just buy the locking solution from some Chinese OEM?
Maybe… https://www.aliexpress.com/wholesale?catId=3010&SearchText=f... (the case looks a bit different though) From an article linked elsewhere in this thread: > startup […] has claimed that issues with manufacturing in China were behind the months of silence which provoked aggrieved backers […] fearing fraud So at least they didn't pretend to make the locks in Canada…
Earlier quoted context omitted.
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…
Allowing HTTP is not insecure; if someone can intercept the connection, they can do so even if you don't have HTTP enabled.
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.
Earlier quoted context omitted.
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.