raesene3

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)

nope and not only that it's not even supported AFAIK

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.

I did a talk last year for OWASP AppSecEU that covers this kind of thing. https://www.youtube.com/watch?v=Wn190b4EJWk

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.

The Video is also up on Youtube and adds quite a bit to the slides including some good demos

https://www.youtube.com/watch?v=nuruzFqMgIw&list=UUJ6q9Ie29a...

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)

That's different to the PIN. CVV is for cardholder not present transactions, PIN is for one's where you're there.

Also CVV needs the 16 digit card number, card holder name and expiry as well..

I'd almost guarantee that trying to brute-force a CVV number will get your card blocked real fast.

What makes you say that? Microsoft have been providing warning of XP going End of life for years now, and (AFAIK) they already supported it for longer than other OS vendors do for desktop OSs.

It hasn't been the current offering for them for 6 years and there's been 3 major releases since it...

Ultimately there's got to be a cut off for support of any software product...

What I think is interesting about this is more the general case than this specific example. I'd say that people's social media handles are becoming more and more important to them, so loss of them becomes increasingly bad.

A lot of people in the tech world are probably more known by things like their twitter handle than their real name.

With free services (and indeed perhaps with paid for) there's not a lot to stop a company changing the ToS to allow for usernames to be transferred as they like(assuming it's not already in the ToS).

Now if your chosen handle is pretty niche (no one who's not a fan of 90's ADnD settings is likely to want mine), it's probably not a big risk, but for other ones it seems plausible to suggest that a company might start seeing them as a valuable asset, to be monetized..

Interesting to see this hit big companies like google. The problem, I think, stems from the idea that most people treat XML parsers as a "black box" and don't enquire too closely as to all the functionality that they support.

Reading the spec. which led to the implementations, can often reveal interesting things, like support for external entities..

Hopefully one positive thing that will come out of this whole Heartbleed thing is that companies making extensive use of Open Source software for security critical purposes will consider contributing to ensure that security reviews are carried out on them.

The cost of regularly reviewing codebases like OpenSSL would likely not be that high when compared to the potential impact of a breach because of a flaw in the software.

If you're worried about not being able to get access to "security people", I'd recommend looking at OWASP (http://www.owasp.org) which has a lot of good free information and also chapter meet-ups which are free.

Interestingly one of the problems I've faced running an OWASP chapter is how to get more developers along to it.

Also security.stackexchange.com can be quite useful

An interesting point, but if interpreted by the wrong person, using wpscan (which makes a load of requests to the site) could be considered dubious under the CMA (I definitely wouldn't run in against a site which I wasn't authorised to test)

From what I know vulnerability scanning (which is essentially what wpscan does) is a bit of a grey area under UK law.

It's been likened to someone "rattling the windows" of a house. They may be doing it with the intention of notifying the owner that he's left his house unlocked, or they may be doing it to attempt to gain unauthorised access..

The analogy isn't perfect but it's one I'd step carefully on.

One thing that to consider is that in UK company cars provided to employees as benefits are taxed heavily based on emissions, which is what drives a large number of customer to small engine diesels (hence the popularity of the BMW 520d amongst company car owners).

In that market assuming that tesla would be in the best emissions category, I'd expect them to do really well.

Sure in a consumer scenario 2 years is the norm. What I was thinking of is that corporates are not used to 2 year lifecycles so there's likely going to be problems for them if they don't budget for that.

This is a great illustration of why Android is likely to face problems in corporate deployments. Lack of security updates less than 2 years after release is likely to prove a serious problem for companies who operate a 3-5 year device refresh lifecycle...