I don't understand why Microsoft is not given more flack for this decision.
Your alternatives is to not use their cloud, or use 4 digit PIN or a series of screen swipes, but they don't support a local password. If you understand how to set it up, you can supplement the PIN/swipe with a USB key, but it is not a visable user option and you have to understand what your doing.
That the details differ on different accounts of what happened after the resurection, I don't see as a test of anything. I can see the differences explained many different ways, and even the oppositie of what you are trying to imply, you could say they appear more authentic since they are not exact copies, or you could say they took different accounts, or they were trying to emphasize different themes, or a bunch of myths assembled seperately.
If you are trying to argue that Jesus was doing what many of the other Jews at the time were doing, it sounds like that is just a guess, and you have no evidence for what you are asserting. Or if you are not just guessing, what is the evidence?
19Jesus answered them, “Destroy this temple, and I will raise it again in three days.”
20They replied, “It has taken forty-six years to build this temple, and you are going to raise it in three days?” 21But the temple he had spoken of was his body.
22After he was raised from the dead, his disciples recalled what he had said. Then they believed the scripture and the words that Jesus had spoken.
What inside information does Reza Asian have that the Bible is wrong?
Along with your 2 way authentication proposal, establish an authentication protocol with acceptance level similar to SSL that allows the authentication to be done securely between key manager on the client side (away from any trojans or keyloggers) and a user/key database on the server side (away from any hackers). This way way we can keep the most sensitive information (the keys), in a simple isolated device or server, that does one thing, manage keys, thus drastically reducing risk of being compromised. Also, a well established authentication protocol standard, is needed if we want to rid ourselves of using passwords (not just for browsers, but also applications).
I think what you are trying to say is that a society without laws and strong government (a perfect libertarian society?) allows for extreme groups to rise and take over. So maybe you should have said "What happens in a perfect libertarian society. Rand Paul eat your heart out!". However that would be very misleading, because Rand Paul is a strong believer in the constitution and does not beleive in a lawless society.
The idea of testing the implosion device was brought up in discussions at Los Alamos in January 1944, and attracted enough support for Oppenheimer to approach Groves.
You could go as far as proxying the entire secure connection through the security device, but I would still securily tunnel the authentication protocol inside the encrypted TLS/SSL connection rather than combine them in a pure TLS/SSL solution for various reasons.
The username and password are vulnerable because:
1) They are typically exposed on the same system that handles the connection, which makes them vulernalble to trojans, key loggers, hackers, etc.
2) They must be managed by humans or vulnerable password managers.
3) They don't authenticate the server, making the user completely reliable on SSL certificate mechanism for authenticating the server, which as we are aware has a number of weaknesses including most browsers allow a user to ignore a bad certificate and bad certifcates can be trusted through accident or malicious intent.
Having a well designed protocol underneath SSL to authenticate between the client and the server that:
1) is key based
2) has bidirectional authentciation
3) allows authentication to be done on an isolated computer or dedicated security device
Would go a long ways towards improving security.
Maybe there is an existing protocol that provides some of this, but I don't believe OAuth on its own does.