As I answered above, that is true. Unfortunately, this is one of the many cases in which they (the companies implementing the security options) chose usability over security.

Unfortunately, there is no magic bullet here - very strong security would lead to many users being locked out of their accounts, and many very unhappy customers (who will happily scream at the support people, even when they are themselves to blame for locking themselves out - maybe by losing the security key, or forgetting their passwords, etc).

Even Google offers alternatives - when logging in these days, you have at least 5 or 6 methods of verifying your identity (approval on an Android device, U2F key, Authenticator, offline codes, SMS codes, pre-generated keys, etc). All of them equivalent - if a single one of those is compromised, so is your account. This is somewhat mitigated by the "new login detected" prompts and emails, but it does remain a valid security concern.

Well, I won't argue with you there :) . It's one of those cases in which they choose usability over security. :/

Your shift key seems to be stuck :)

There is a reason for requiring your phone number - most likely, they are using SMS as a backup recovery mechanisms - so that you are not "toast" when you lose your security key. If you lose the physical key, you will still be able to recover your account via SMS.

Google Authenticator is nice, but:

1) it is vulnerable to man-in-the-middle and phishing attacks. While U2F is designed to resist those (if someone gets a user to generate a code on a phishing website hosted on "goog1e.com", that code will not work on "google.com").

2) it is impossible to backup the keys. Lost/destroyed/changed your phone? You're going to spend the next two days resetting 2FA on all those accounts... (I know there are workarounds for this second part, but some of them trade convenience for lower security...)

Oh, you would be surprised how many people do... There have been plenty of attacks in the wild doing exactly that - persuading people to give out 2FA codes (from Steam Authenticator codes to banking token codes). And it is amazing how many people willingly hand them out.

That's the beauty of U2F - the generated code depends (among others) on the actual URL. So if you get a phishing link on goog1e.com, that site will receive a totally different 2FA code, one that will NOT work on the original website.

More details here, for example.

The downside of this design is that it requires support from the browser (someone has to provide the actual URL when requesting the 2FA code), and major browser manufacturers don't seem that eager to implement it. Maybe the new WebAuthn standard will change this...

Do you have a reference for this? Because Wikipedia (also linked by the parent) seems to contradict you... https://en.wikipedia.org/wiki/...

Because so far it's the best we have. And because security is only as strong as the weakest link.
You seem, however, to disagree. What would, in your opinion, be a reasonable standard for end-to-end security?

I'm not sure what you mean by Mozilla "blacklisting" basic encryption. As far as I know, self-signed certs work just fine in Mozilla. With a warning, of course - as it should be (and IMHO, that warning should be much stronger than it already is).

You seem to forget that the web is not only visited by people like you, me, and most of the /. crew. Average Joe doesn't know how to look at the lock bar, and he doesn't know how to check if a certificate is valid. And this makes him the point where encryption without trust falls apart.

And since you seem intent on throwing NSA around - while it may be easier for them to just sniff traffic, they really have no problem in mounting a MITM attack (see links in my previous post). And while it has not been proven yet, they might just as well have the ability to generate their own certificates, trusted by the major browser vendors (see here - but again, keep in mind that this is just speculation at the moment).

So even if we have encryption+authentication, it still may not be enough. Not when faced with an attacker which has the resources to break the chain of trust.

I won't even get started on the fact that the NSA has knowingly attempted to compromise encryption standards. :)

I forgot to answer your question...

No. I never said that it is less secure. I said that once you start blindly accepting self-signed SSL certificates, you are no longer secure. Maybe not as insecure as with clear text, but definitely not too far away from it.

I will grant you the fact that unencrypted connections are vulnerable to both sniffing and MITM, while self-signed certs are "only" vulnerable to MITM. But you seem to believe that there is a huge leap from sniffing to mounting a MITM - and this is where we disagree. While MITM may incur an additional cost for the attacker, it is far from being an unrealistic scenario (see below for some examples).

As for the rest of your rant^H^H^H^H post, it doesn't really make sense. You believe that a self-signed certificate will somehow "protect" you from the NSA? Who is somehow incapable of a MITM? Well, this, this and this may prove... enlightening. And while we're on the topic of "additional reading", may I also recommend "Alice in Warningland" - a study showing 70+% clickthrough rates for SSL warnings.

There are some other issues, like you mentioning wireless traffic. With WPA2 being the default, and with many modern wireless NICs no longer supporting promiscuous mode, it is often more difficult to sniff wireless traffic than to mount a MITM on a wired network (especially when the target is the victim's router - again, see the links above).

Security means encryption + integrity + authentication. Period. Anything less is no longer secure.

So basically all this does is to force HTTPS requests instead of HTTP? (took me a while to find out - gotta love the fact that the "clever technology" link on their site, instead of going to a description of the actual technology, goes to... xkcd?! :) )

I see a few problems with this approach:
1)Not all content is provided over both HTTP and HTTPS. For multiple reasons, one being performance. Which leads us to the second problem...
2)A HTTPS session incurs a significant overhead for encryption. Which may be no problem for someone like Google. But for someone hosting his/her own (moderately successful) website on a small server, it might just overload said server.
3)Quite possibly the biggest problem with HTTPS is the fact that users have been trained over many years to just click "accept/install certificate" on self-signed certs. Not knowing that if you do this you are no longer secure.

And the more we keep forcing HTTPS, the more webmasters will use self-signed certs. Not many people want to go through the hassle of obtaining (and maintaining!) a valid SSL certificate for every single website they run, even if that cert is free. Which will only exacerbate the problem...

Nope. For all the reasons I explained to you previously, chief being the fact that IPv6 is 100% incompatible with IPv4 on the wire.

True. And just as true is the fact that tunnels only solve half the problem. Yes, they help getting new IPv6 hosts to talk to each other (over a potentially non-IPv6 compliant infrastructure). But they do not solve the bigger issue - getting new IPv6 hosts to talk to existing IPv4-only hosts (like, I don't know... the entire Internet?!).

And once again, I strongly suggest that you should read and understand the term "compatibility". I'll give you a hint: "just use the old protocol at the same time" isn't it!

Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.

In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?

And in the second case, there's no way to do dual stack anymore - and where's your "simple mechanism" then?

I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).

In one of my previous posts, I linked to the definition of http://en.wikipedia.org/wiki/Backward_compatibility. You either didn't read it, or didn't understand it - the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it.

I'm not saying that the exact same solution that was applied for BGP could be used for IP. They are completely different protocols, with different sets of rules. I just gave you two examples of what real compatibility looks like, since you still seem to believe that 6to4 offers it.

By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.

Totally agree with you - it's basically the only solution we have right now. But the fact that it's the only solution doesn't make it a good one. Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.

And before you say "no problem, at that point we'll just turn off IPv4!", keep in mind that this will not be possible until there is no IPv4 Internet to speak of. How long do you think that will be? My guess would be on the order of decades...

A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails.

And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything? Please don't forget that we are talking about the transition here - that transition being done by using dual stack.

Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).

This is called actually the important part of the transition strategy. And it is completely missing in IPv6.

And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".

I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.

No need for sarcasm - I really don't feel the need for this to degenerate into a flame war. You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.

And yes, dual stack does exactly that - run two separate networks, totally separate from each other ("ships in the night"). And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary (your misnamed "transition period"), and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?

Do you have a reference for that? I did notice the behavior in operating systems ("ping 127.1" translates to "ping 127.0.0.1" in both Windows and Linux), but I was never able to find an RFC that talks about it.