11–20 of 102 posts
Nothing went right in the design of this padlock.
Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
Maybe they took the „f*ck it, ship it“ advice too seriously and shipped it a bit too fast? Who knows but after learning this I would be highly cautious to buy anything from this company until they‘ve proofen to be more careful in the future.
Being a Kickstarter project, the pressure to meet production deadlines is severe, and any technical debt inherent since the 'quick and dirty' MVP probably stays unpaid.
Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
Out of interest what strategies could be implemented to avoid this? I've worked as a developer for a number of companies who handle sensitive data and I could have fairly easily have pushed malicious code. Even with mandatory code reviews, significantly complicated code with a well placed security hole would likely be missed.
Does this mean I should turn off HTTP completely? Right now, I redirect any incoming HTTP requests to HTTPS. Is this considered insecure?
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 with bolt cutters that leaves a mark. With a high tech back it doesn’t (unless they record and you actively look at unlock attempts). Which means that to find out if your lock has been hacked you’ll likely have to physically go there, open it up, and then look inside to see if anything is missing.
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…
The vulnerabilities in the article might go unnoticed, so the user keeps locking gates, chains, whatever with the bad lock and the crooks can come again and again and rifle through your shed, garage, whatever.
It is absolutely worse than a chopped padlock.
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?
Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
Out of interest what strategies could be implemented to avoid this? I've worked as a developer for a number of companies who handle sensitive data and I could have fairly easily have pushed malicious code. Even with mandatory code reviews, significantly complicated code with a well placed security hole would likely be missed.
1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable. Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.
2. Novice / Amateur attacks on the API or backend - make sure as much security as possible is in global middleware on the application, on by default, opt-out explicit. Long random access tokens, use either DB checks or constant time comparison to verify, do rounds of self and third party testing to make sure there's no cross privileges or escalation.
3. Protect against ourselves going rogue / being compromised - all keys in a HSM, the HSM also has the list of certificate chains it will trust, only modifiable by N of M keycards held by top execs, assume compromise at every stage and design the systems to mitigate impact. Ideally design so catastrophic attacks are impossible without collusion among top level company execs, and all other attacks, even when successful are downgraded to inconveniences, preferably minor.
Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
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…
Are you being obtuse? I'm worried about the options that are 1) easiest to perform and 2) arouse the least suspicion.
So, obviously the first two by a mile. The tech is not advanced.