raesene4

Especially when most stripe using sites embed the payment request in their page and there's no way for end users to tell that it's using stripe without looking in the source of the page. If that got re-directed by an attacker 99+% of users wouldn't notice I reckon.

Traditional banks are very risk averse and have large investments in older tech.

It's a brave company who chooses the ground-up re-write of a core system in the banking world.

One of the more interesting aspects of Mondo is from their blog they appear to be building their software stack from the ground up, as opposed to taking the approach of other new banks and buying in/white-labelling core systems from established providers.

So it'll be interesting to see if a set of new FS companies grow up who aren't dependent on legacy systems. If they do you could see a world where they can more easily interoperate without a descent into mainframe batch land :)

There's quite a crop, some of the ones I've seen so far

- Starling http://starlingbank.co.uk/ - Tandem https://tandem.co.uk/ - Loot https://loot.io/ - Fidor https://www.fidorbank.uk/ - Metro (been around a bit longer but still relatively new) https://www.metrobankonline.co.uk/ - Aldermore http://www.aldermore.co.uk/

I'm not sure I'd class Mondo as a "passion Project" they're a company with a product in alpha (payment card) and in the process of getting FCA accreditation, which requires quite a bit of work to get started on...

As to whether their vision of financial services takes off, I think that remains to be seen, but it's very interesting to see the large number of new banks starting up in the UK market which has previously been dominated by a few large players.

to provide some context on the newspaper that this article is on. The national is a newspaper specifically set up at the time of the Scottish Referendum to provide a more nationalist viewpoint to counter the perception that the mainstream UK media had a Unionist slant.

There's quite a few ways to get started with the skills you need for pen. testing and the good news is that a lot of them are free or low cost.

You should probably start by picking an area that you're interested in (e.g. web, infrastructure, mobile) as whilst there's some commonalities each area has it's own toolset and specific areas of focus.

For learning there's things like https://pentesterlab.com/ , https://www.offensive-security.com/metasploit-unleashed/

For practicing legally , a lot of CTF competitions make use of skills which are useful for penetration testers, also places like vulnhub https://www.vulnhub.com/ have downloadable challenge machines that you can run in a VM.

In terms of meeting up with people in the industry, look out for local Defcon chapters or B-Sides conferences, both of which tend to be free or low cost and have some good content.

Absolutely! Although that said not all of them store creds in dot files by default...

If you want to be concerned about the npm chain of dependencies model, one thing you should probably think about is that there is no curation of code on npm, so a package could be malicious (e.g. if an attacker compromised a set of package maintainer creds from a dot file) and npm packages (like most package formats) have the ability to execute code on install...

Ruby will but it's an API key not creds directly. Python probably will, IIRC it's not auto-created but is general pratice to put creds in a dot file for PyPI. Go doesn't really have a widely used package manager in that sense, people use github repos (and go get) from what I've seen. Not too sure about PHP and Lua...

FWIW user namespacing is already available in docker experimental and will hopefully be getting into mainstream soon...

protecting the other 99% of their users from an attacker loading malicious firmware onto their device?

how are you handling the problem of banks revoking customers online fraud guarantees if they make use of 3rd party services to make transactions?

From what I saw of the aggregation sites that pulled details from UK banks in the past, this was a major stumbling block...

EV certs will only make sense (for the vast majority of sites) when consumers start actually recognizing the difference between EV and DV, personally I don't see that happening real-soon as many non-technical consumers don't even notice if there's no SSL cert at all...

Ask yourself do you remember what sites use EV certs and would you notice if one had a DV instead... if you wouldn't ask yourself why a company would pay more money for that EV cert, when they can get a perfectly good DV one for free

That's an interesting opinion... what makes you think it's the easiest OS to target? Do you have any data to back up the claim that a modern Windows OS is less secure than it's major competitors (OSX and, in some circumstances, Linux)

My feeling would be that Microsoft have done a lot in the security line and have also given a lot back to the security community (their SDL documentation which is freely avaiable for example) and that they are one of the better examples of security in the software industry these days

For me, the business model of this kind of service is important. Where a commission is paid by the dealer to the service, it would seem to me that there's a potential for a conflict of interest as the service gets more money, based on how much the dealer charges for the car. In that kind of setup is there really a good incentive for the service to haggle hard on the customers behalf...?

I'd prefer a payment model based on either a flat fee paid by the customer, or perhaps something based on the amount saved from the list value of the car.

I'd agree, I was just pointing out the basis that the author was coming from which was the reason why he was considering seasonal variations in battery calculations.

With that said, from reading some articles about off-grid living, it's not outwith the bounds of possibility that people are looking at pure solar (or pure renewable anyway) off-grid living, for priniple-based reasons , rather than a more pragmatic rationale.

well nobody apart from people looking for an off-grid lifestyle of course. What I took from the article is that pure solar off-grid is impractical away from equatorial latitudes.

I think the original article was looking at the proposition of off-grid energy use using purely solar, in which scenario seasonal variations matter

From the article "Even with these rough numbers it’s hard to see how anyone living any distance from the Equator is going to be able to justify the cost of installing enough batteries to go off-grid with a domestic rooftop solar PV installation."

I'm going to have to disagree with your point about banking applications based on my experience (~15 years) in banking IT and security.

Whilst obviously Internet facing apps are treated with more caution, it's definitely not true in my experience to state that there are no security demands on internal applications. I would expect that most/all banks these days realise that there's no such thing as a fully trusted network...

oh sure, in an ideal world the dev kit would have all the capabilities of the live consumer device.

But when you're developing a new category of device, that's not always possible.

For a very related example, look at the Oculus Rift approach to VR. they've been iterating on developer kits slowly improving the hardware while letting people feel out how to use that class of device.

Ultimately it'll be down to individual dev. houses whether it makes sense for them to invest at this stage, or wait till it's closer to consumer launch

I'm not sure the narrow field of vision is that important for a dev. kit. The goal is to let people work out how best to produce apps for this kind of interface.

If they can't sort it for consumer release, that's a much bigger issue of course. My guess (and it's just that) would be that they'll be trying to improve field of vision for the consumer release, as from the reviews I read it was the one major negative people cited.

so with two patreon style sites both of which say "we take security seriously" , until they have a breach, how would you judge which one would take better care of your data?

The information (AFAIK) about their security mechanisms only got released as a result of the breach, so even assuming you knew what the terms were and how to judge good security from bad, you wouldn't have the information until the site got compromised.

This is a very common problem, some more examples here http://raesene.github.io/blog/2014/06/08/finding-security/

I like patreon a lot and feel sorry that they've been breached. Luckily (for them) I'd guess that with the number of breaches these days, the negative publicity on them will be a lot less than it would have been a couple of years back, so hopefully they'll be able to carry on ok.

You can't :)

There is a huge Market for Lemons (https://en.wikipedia.org/wiki/The_Market_for_Lemons) style scenario in IT systems with relation to security.

Everyone will say "we take security seriously", but there's no way for ordinary consumers (or indeed most companies) to determine what the company meant by their statement, and to evaluate the relative security of the systems of two companies.

This could actually provides a market incentive for companies not to spend too much on security, as those that do will have lower profits than those that don't.. until they get breached, and even then companies with good security can be breached...

sure for some attacks it might help, but ultimately if someone has compromised your server, that server is likely to have the ability to load the key to decrypt the data.

For example to handle the case of unattended server reboot, you'd be likely to have the server have a script to load the key back into memory. Attacker gets shell access, they get the script, they get the key...

Security is always a trade-off and people tend not to engineer their webapps with the assumption that they'll be breached in specific ways.

the problem is, if you intend to use the data within the application, you need to be able to decrypt it. If you can decrypt it, so can anyone who compromises the website :)

with e-mail addresses you need to use them in their unencrypted form (e.g. as login names), so encrypting wouldn't do much for you against most attacks.

Of course, but the article being discussed is about curl|bash so I felt that comment was relevant :)

This is why signatures should be embedded into the packaging and distribution mechanism, to reduce manual steps.

Looking at Dockers deployment of Content Trust as an example of this.

You still have a trust decision on first use, but it's better protection than nothing.

But curl|bash is a one step process, as soon as you get the script you execute it, with no opportunity to check a signature...