Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IOT Developer Security Checklist

simplesecurity.sensedeep.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: IOT Developer Security Checklist

#11

Post by aeronautic »

pavement wrote: post #6
MattBearman wrote: post #2

I feel like the first two items on this list should be: - does this really need to be online? - really ?

I like to use the XYZ metric. (aka: eXamine Your Zipper ) 1. Does the zipper on the fly of your pants need to be automated? 2. Does the zipper on the fly of your pants ever need costly repairs? 3. Does the zipper on the fly of your pants need regular maintenance? 4. Does the zipper on the fly of your pants expend disposable accessories? 5. Does the zipper on the fly of your pants need to be context aware? 6. Does the…

Love it.

Re: IOT Developer Security Checklist

#13

Post by mmalone »

pyre wrote: post #4

Maybe I'm missing something, but is the general consensus on HTTP Auth that it's poor security? I've seen is suggested a lot of (e.g.) authentication in webapp api scenarios. Specifically to use it to pass the initial username/password, and then stuff an session token into it (after login). What are the added security risks of this (so long as it's done over HTTPS)?

For webapp API it's pretty much the same as any other header, but with a subtle semantic indication that the value associated with the header is being used for authentication. Generally the value is a password or a bearer token. The problem is that this token is usually not channel bound (can be stripped and used elsewhere) and often has broad authorization associated with it. The security characteristics depend on lots of details. Usually when people say not to use HTTP Auth they mean don't send the username / password in base64 encoded cleartext over the open internet, as suggested by early HTTP RFCs.

Re: IOT Developer Security Checklist

#14

Post by [deleted] »

pyre wrote: post #4

Maybe I'm missing something, but is the general consensus on HTTP Auth that it's poor security? I've seen is suggested a lot of (e.g.) authentication in webapp api scenarios. Specifically to use it to pass the initial username/password, and then stuff an session token into it (after login). What are the added security risks of this (so long as it's done over HTTPS)?

[deleted]

Re: IOT Developer Security Checklist

#15

Post by elihu »

aeronautic wrote: post #10
MattBearman wrote: post #2

I feel like the first two items on this list should be: - does this really need to be online? - really ?

I know! Why do device manufacturers need to be pushed for this? We consumers keep buying stuff that has been put on the internet with little to no thought about security today or tomorrow. IOT will get much worse before it gets better. I say this from working with device builders for 2 decades. The level of attention to security is sadly lacking.

I think that consumers aren't actually the target market for most of this always-connected-always-listening device stuff. The real products that are for sale are the data these devices generate and the distribution channel that third parties can buy access to that these devices enable.

There's an old saying that "if you aren't paying for the product, you are the product". That saying might need to be updated to reflect modern times, that "if you aren't paying for the product and maybe even if you are, you are the product".

There may also be some manufacturers who put stuff on the Internet not as a deliberate effort to monetize their customer's lack of privacy, but simply because they've bought into the marketing of other device makers and are convinced that some of the features they can enable by being always connected will make their product more desirable.

Re: IOT Developer Security Checklist

#16

Post by aeronautic »

trobayhasteman wrote: post #12

Sure the list has valid points, but those don't pertain anymore to IOT than any other internet connected application.

True point. The difference is that enterprise apps understand the need to patch and update. IOT devices and device builders largely do not.

IOT devices today look pretty much like any other internet device too. Linux, good CPU horsepower, ample memory and internet connection. More than a few exploits that work on enterprise servers can be adapted for IOT devices.

Add to this a lack of awareness of basic security issues among device builders and you've got a problem. That is why we are seeing so many security issues with IOT devices.

Re: IOT Developer Security Checklist

#17

Post by ohazi »

There's a fundamental problem here, and I don't know how it should be addressed. I agree that manufacturers should be able to silently patch firmware for security holes. But I decidedly do not want them silently adding, removing, or changing functionality.

I find this practice absolutely infuriating, and it's a big reason why I abhor the current IoT ecosystem. Sometimes I get busy and don't have time to read a changelog, and I don't want to have to do this on someone else's schedule.

There seems to be no technical way to allow manufacturers to provide transparent security updates without also allowing them to pull the rug out from under you when you least expect it. I think we need some sort of social contract for this, but unfortunately my view seems to be a minority one, given the amount of bullshit that the public seems to tolerate from self-updating devices and apps.

Re: IOT Developer Security Checklist

#18

Post by jessaustin »

aeronautic wrote: post #7
pyre wrote: post #4

Maybe I'm missing something, but is the general consensus on HTTP Auth that it's poor security? I've seen is suggested a lot of (e.g.) authentication in webapp api scenarios. Specifically to use it to pass the initial username/password, and then stuff an session token into it (after login). What are the added security risks of this (so long as it's done over HTTPS)?

Do you mean basic & digest http auth built into the browsers? If so, yes, they are bad. The issue is you cannot reliably implement log off on all browsers.

Is this still true, for any browser that is still used? It seems a couple of decades would be long enough to get this right...

Re: IOT Developer Security Checklist

#19

Post by jessaustin »

pavement wrote: post #6
MattBearman wrote: post #2

I feel like the first two items on this list should be: - does this really need to be online? - really ?

I like to use the XYZ metric. (aka: eXamine Your Zipper ) 1. Does the zipper on the fly of your pants need to be automated? 2. Does the zipper on the fly of your pants ever need costly repairs? 3. Does the zipper on the fly of your pants need regular maintenance? 4. Does the zipper on the fly of your pants expend disposable accessories? 5. Does the zipper on the fly of your pants need to be context aware? 6. Does the…

I'm afraid #9 is only a matter of time... sort of the same idea as the "Progressive Snapshot" device.

Re: IOT Developer Security Checklist

#20

Post by aeronautic »

jessaustin wrote: post #18
aeronautic wrote: post #7

Earlier quoted context omitted.

Do you mean basic & digest http auth built into the browsers? If so, yes, they are bad. The issue is you cannot reliably implement log off on all browsers.

Is this still true, for any browser that is still used? It seems a couple of decades would be long enough to get this right...

Still true when I tested last year. The core protocol does not have a defined way to get the browser to forget the login.

You have to resort to different fudges on different browser.

Net/Net: the http auth ui sucks, has bad usability, weak crypto, and is not robust with logout.

HTML/form based auth can be made robust and is a preferable alternative in every case.

Post reply on HN