troyhunt

Not at all, I continued writing a lot on Twitter and still love the product. I don’t like the way they’re handling this situation though, more in this vid from a few days ago: https://www.troyhunt.com/weekly-update-289/

Try this: http://www.troyhunt.com/2013/12/working-with-154-million-rec...

This might answer your question: haveibeenpwned.com/HowFastIsAzureTableStorage/?email=foo@foo.com

I'm writing up how the back end is done and will post it in the next day or two, IMHO it's massively impressive but also very easy :)

Oh hey, welcome back :)

The viable alternative is in the sentence you quoted:

"Ultimately, password hints are evil and they add nothing to an online system that can’t be achieved with a secure password reset feature."

Secure password reset.

Hey, thanks for pointing that out, that's the second time I've heard that recently. I think Ghoetery is getting a little over-excited and hiding the parent element containing Disqus which also contains the body of the post. I'm going to take a look at how to rejig the markup so that this doesn't happen in future.

It's harder to detect the framework when ASP.NET MVC is used. No view state in the source code, no .aspx extensions and the server response headers identifying IIS and ASP.NET can be removed. There's always HTTP server fingerprinting but you're moving on past the low-hanging fruit now.

There's a good NuGet package for dealing with this now: http://brendanforster.com/blog/custom-server-headers-bad-for...

What it shows is that the server is not configured to return a custom error page when an exception occurs. Beyond the obvious usability issue, this may be used by an attacker to identify sites that leak internal information. It's not a vulnerability per se, but it's a gateway to helping find them.

More info: https://asafaweb.com/Scan?Url=telegraphcottages.co.uk#Custom...

Because rightly or wrongly, there's evidence that it increases consumer confidence and results in more purchases / subscribers / customer love. It's an empty promise, but people buy it anyway.

If there was something worth protecting on a personal blog site, it might be a different story.

1 is very on-topic - there's no way that data should be sent in the clear.

HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.

Years and years of experience? Often not, and that's speaking from years and years of experience!

Vast sums of money? Yes, at least the outsourcing vendors who churn this sort of thing out.

Unfortunately you're the exception Mark so good on you for that. Well I mean unfortunate for the greater web using population, but very fortunate for you!

Which bit was that Toshio? I can't see any MS defending, the post essentially said "This is what's happening, here's what to expect, these are some of the considerations". Whether what MS has done around OS and browser integration is wrong or right is not the issue, what we're all going to do about it is.

Yes - education! Your average desk jockey will know when the sites they use break, they won't know why and they won't know about the alternatives.

I'm not so sure that this is to their commercial advantage, in fact I think it could be quite the opposite. Where there is the motivation (i.e . by those managing the desktop environments), the IE8 dependency is an easy one to solve via alternate browsers. This, of course, takes people further away from the MS stack.

In most managed corporate environments, you do have to run IE. The freedom of installing your own software at will doesn't exist.

Given the web is credited as being created by a Brit in Switzerland, I think we can all agree that both its origins and its intent are international in nature.

Given that uncultured in this context is about lack of awareness of cultures beyond their own, your definition seems consistent with mine.

That's a bit of an "it depends" situation though. There's a good answer on Super User about this: http://superuser.com/a/156969/4682

Well actually, we are talking about JavaScript, 5 separate .js files actually.

The challenge comes back to the fact that "Secure" in an HTTPS context is an absolute; either everything is loaded over HTTPS and you get a shiny padlock or it's not and you get a red cross (depending on the browser, of course). The browser itself obviously cannot discern what the developer feels should be loaded over a secure channel and what should not nor is there anything in the HTML/HTTP spec to support this (other than HSTS to force HTTPS).

The simple reason not to serve up HTTP content on an HTTPS page is that rightly or wrongly, the browser will tell your users that your site can't be trusted. I understand your point, but that's the implementation you'll find in the browsers of today.

Facebook is definitely a high value target, just ask a Tunisian who was using it early last year: http://www.thetechherald.com/articles/Tunisian-government-ha...

Not having HTTPS everywhere by default (although at least it's now a configurable option) is extremely serious for a site like Facebook. The fallout from governments monitoring political dissidents is just one example, the potential harvesting of personal information (including connections) is another that's closer to home. Remember Firesheep? http://en.wikipedia.org/wiki/Firesheep

Why doesn't Facebook force it everywhere? Perception of processing overhead (although debunked by Google), integration impact with non-HTTPS content (impact on ads has long been claimed as a barrier), re-engineering of one of the world's largest sites, etc. But it's heading in the right direction, Twitter, Facebook and Hotmail, for example have all made positive steps forward, I'm sure we'll see a much greater prevalence of HTTPS as time progresses.

The relevance is that none of the additional protections added to the technologies are available. We're in a very different threat landscape today than what we were in 9 years ago and the technologies provide advances to better protect ourselves. If you're using them!

Why rewrite? When there's a new major feature release, take the opportunity to change the target framework. Most servers also have a refresh cycle so update that at the time and roll it into the testing procedure. I'm not saying do this immediately after every new IIS / .NET release, but going 9 years without change is risky.

GMail is a good example of HTTPS everywhere.

When you embed HTTP elements you can no longer trust their authenticity. If, for example, you load JS into your banking app over HTTP it would be possible for a man in the middle attack to substitute it with a script which could re-write the page or siphon off sensitive data.

HTTPS says "We can verify the site you're connecting to and all data transited between it and yourself is encrypted". Embedded HTTP content invalidates that premise.

Actually, you do a lot with them; I could take a significant portion of them and log on to the account holders' Twitter / Facebook / GMail. Reuse is rampant and anyone who holds credentials has a duty of care to protect them.

I totally agree, which of course is why they shouldn't be commenting on it! But regardless of the Customer Care's Twitter account, their messaging is consistent with the misunderstandings demonstrated throughout the website.

Yeah, but statistically even the loyal sausage dog would have a better than average chance of having moved on since the ASP launch! (10 years ago avg age would have been < 10 years)

Actually, I think it's very clear there were just a lot of bad dev practices happening across the different technologies. Classic ASP on Impact Data, PHP on the main Billabong site and current day .NET on the store. Clearly bad things were done on all.

However, some of those basic injection flaws in classic ASP would not have been possible on a more modern technology stack be that from Microsoft or other. A 5 year old version of PHP also isn't going to do you any favours. Newer frameworks are simply better at saving you from yourself - but that doesn't excuse the sloppy practices.

Quite right, and I did refer to that, the point was that if you can't get simple things like these right (among others referred to), is it any surprise that a major breach occurs?

Yahoo! have confirmed the breach: http://news.cnet.com/8301-1009_3-57471178-83/yahoos-password...

The emphasis should have been on "common" - there were only 302 emails out of the full sample which appeared in both breaches. I would have like a larger sample size, but that's all there was.

The comic is amusing, but it only works if you can apply it uniquely across accounts. Once you start creating unique passwords of that length you can't remember them. Get a password manager and forget about patterns - the XKCD approach doesn't work without serious compromise.