Ah yes, so the threat model for developer signing is compromise of the repository. So here we're looking at the OpSec of the repository owner (e.g. PyPI, npm, Rubygems etc), and also the risk of deliberate compromise by the repo. owner (for example where a state with authority over the repository compels them to modify a package)
In terms of compromise there's already been the attack on Rubygems in 2013, but in general the thought here is that these repositories are extremely tempting targets for well-funded attackers. A compromise of npm for example would give an attacker direct access to a very wide range of targets.
Combine this with the very limited resources of the repository owners (most are free resources, likely constraining the money available for defence) and you get a realistic risk of attack, which is mitigated by an appropriate use of signing by the developer.
Docker hub has deployed an implementation of the Update Framework to address this, although the interesting point now is whether people actually use it as it's not compulsory...
On the flip-side how is someone who's using a package from one of these repository meant to validate that it's secure and non-malicious?
without central validation, each user would have to do it, and that's frankly impractical...
The alternative is that no-one actually does the validation and runs the risk of insecure or malicious packages. To me, that's totally fine as long as they're doing it knowingly, however I'd suggest that most companies making use of NPM, PyPI, Rubygems etc are not doing it knowingly...
Well if there's no central validation, that leaves all individual users to validate packages before use (which is a huge amount of work)...
The problem is that companies are using these packages as though they are trusted (i.e. not validating them when using them), and that's part of the value proposition in the first place (i.e. it's easier to use this package than write it myself), but it's missing the cost of validation.
On signing I'm not sure we're talking about the same thing. I'm referring to developers cryptographically signing packages before pushing to the repository, with a key that the end-user can validate. the idea is to protect against a comrpomise of the repository. There's a good discussion of the risks and potential solutions on The update framework's site (https://theupdateframework.github.io/)
Yep it's a really nasty problem for any package manager that operates at scale.
The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)
This is very true, but execution at install time (sometimes with root privileges) is a bad idea from a security perspective, especially when it happens with dependencies, which makes it very hard to check all packages that you're installing...
One of the problems is that npm (and others) put their credentials or some form of API token into dotfiles in the developers home directory, meaning that if you can execute code as the user (via social engineering or malware) you can push new packages.
In some cases it's even accepted practice to put the actual username/password in the clear in a dotfile, which means anyone who can even read a file from the users home directory, can gain persistent access to push packages as them...
Indeed package signing is not the holy grail and won't solve all problems, but it is a part of a secure system.
For the problem this blog post talks about, I personally think that keybase is the right solution. You can tie a key to a github repository amongst others and then validate that the package you're installing came from the person who put the code on github in the first place...
Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge.
Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited/no checks for malicious content.
Also as there's no consistent use of package signing by the developer (it's either unsupported or not very used) there is also a risk of the repository itself being compromised.
Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware...
Linux package managers are a different story of course.
I must admit I don't really see this products major benefits over other ways of achieving the same thing (a secondary phone with call forwarding from the main smartphone).
Their price is $100 and with that there's the usual risks of kickstarter delays/cancellations. But as an alternative things like the nokia 130 (http://www.microsoft.com/en/mobile/phone/130/specifications/) are already available cheaper have a longer battery life and proven track record...
That said the kickstarter already has £250k so they've obviously convinced some people!
I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data)
For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV
on your second point, I'd be careful before making that assumption. Without evidence there's no reason to believe that a supplier company will have better security than your own and it's entirely possible they don't.
Also should a supplier suffer a breach they have powerful incentives not to disclose that breach to you, and where intellectual property is involved (e.g. code) the theft may well not become immediately apparent.
However, Micropayments are not the only alternative to Advertising, subscriptions are another choice which only need to be done once rather than repeatedly.
I'd like to see more site offer an ad-free subscription, in the way that Ars Technica or reddit do, to allow for an alternative to using ads to support content I'm interested in.
Patreon has an interesting model for creative content and one which I think will work for content producers who already have a good fan base.
sure but depending on who's paying and how many subscribers you have it can be a decent sized up front expense. I'd argue it's well worth it in the long run but a lot of companies would prefer something which is less expensive per user (to them) so based on phones or soft tokens.
Interesting article, I've always thought that phones are one of the weaker links in the 2FA chain (but a lot cheaper than dedicated tokens).
The general use of SMS/voice mail has another potential weak point which is where people start using VOIP services a lot. If an attacker has compromised someone's client computer with the usual set of trojans and they use something like Skype to receive SMS and voice calls, 2FA which relies on tokens via SMS or voice could be easily compromised as the attacker will already have access to them..
Some of this kind of system won't actually hash the password but encrypt it and use an HSM to secure the keys.
Wherever you see a password prompt where the ask for specific characters of the password, they're either doing this or shudder storing it in the clear.
Very likely to be a legacy back-end system. Doesn't excuse it at all, but that's one I've seen limit banking systems in the past either in password length, complexity or case sensitivity (I've seen some systems automatically upcase passwords without telling you 'cause the back-end is case insensitive)
In terms of compromise there's already been the attack on Rubygems in 2013, but in general the thought here is that these repositories are extremely tempting targets for well-funded attackers. A compromise of npm for example would give an attacker direct access to a very wide range of targets.
Combine this with the very limited resources of the repository owners (most are free resources, likely constraining the money available for defence) and you get a realistic risk of attack, which is mitigated by an appropriate use of signing by the developer.
Docker hub has deployed an implementation of the Update Framework to address this, although the interesting point now is whether people actually use it as it's not compulsory...