Not only that.I recently caught MS lying - When I bought XBox One I had to create Live Account. When I did that I was then asked to provide my cell phone number because "Recent spam activity from your account" required me to verify the account. The problem is that between creation of the account and that supposed spam, there was only 3 minute difference.
Yeah I probably could be little more clear on that ..
Basically I think that it shows that companies like Microsoft do stuff that makes us less secure and violate our privacy and they are have no problem with lying to use to get the information they think they need.
This is less secure. You're down from requiring Something You Have and Something You Know to just Something You Have. Meaning, anyone who has your phone and opens your browser history can find and access your Outlook account.
Clearly, moving from two-factor to single-factor is going to be less secure, but that's not really the question for me. I want to know if this more secure than user-originated passwords?
User-originated passwords can be socially engineered, or just plain guessed. They can be sniffed with a key-logger, or over a non-secure connection. You can steal password databases and run them against rainbow tables, or brute-force them GPU farms. Password re-use also means that you don't have to defeat Microsoft's security to get at the password, you just need to defeat the security of the weakest vendor where that password is used. Some people will even just straight-up tell you their password if you ask them.
Using an authenticator app to generate one-time passwords means there is no database of password hashes to be stolen and leaked, nothing for the user to remember, no password to re-use with weaker vendor, and nothing for an attacker to brute-force. Because the passwords are single-use, a key-logger is of limited value too.
It also reduces the attack surface down from any script-kiddie who can break the security of the weakest vendor, down to people who physically have access to your phone (or can get malware on to it).
Yes, anyone with access to your phone has access to your Outlook, but chances are anyone with access to your phone has that anyway, and your device is probably locked with TouchID or similar.
So, I agree this is weaker than two-factor, but I don't think that's the point.
1. Install a client cert/pairing token/SSH key/etc. onto each client device;
2. ask the user to configure a password, with a recommendation that that password be short and memorable rather than long and unwieldy;
3. either encrypt the device-credential with the user-password, or send the server the password to hash and store;
4. if the password challenge-response is on the server, have the server validate the device credential "before" or "outside of" accepting password-auth challenges (e.g. in the case of a client cert, validating the cert at the TLS level before the auth request can even reach the backend.)
In other words, systems isomorphic to the financial chip-and-PIN system: the chip is something you have, while the PIN—something you know—is only there to prevent robbers from using the chip, rather than to provide any cryptographic security.
> - You can set a policy on password length/characters, making them hard to guess.
And hard to remember, so users will write them down, lose or forget them, thus requiring costly and insecure password recovery mechanisms. It's not at all clear that passwords actually add any real security due to these issues.
We had a panicked client ring us up one morning after their office had been broken into and computers were stolen. They'd been writing all their passwords on Post-It notes, which they then stuck to bottom of their screens.
how is it single factor if your phone is locked? first you have to unlock it and then you must approve it in app which generates codes in background, that's two factors for me (but yeah, by this counting 2FA is for most users actually 3FA)
Only one factor is required by Microsoft. You may require multiple factors of authentication to unlock the single factor Microsoft requires, but Microsoft still requires only one.
I think it's a big deal for important stuff like banks and email but for most stuff I don't mind if it's tied to a physical object. Interestingly, my house is secured by a physical object (the key) and it seems sufficient.
Your address isn't a secret, and the "something you know" part of TFA isn't supposed to be common knowledge. To stretch the metaphor, your address is your user name, not the password
It could be the same with a phone (username / phone). I figure between my phone having a password and (I assume) the fact that I would be able to revoke authenticator access to a device quickly I would be comfortable with the risk. I honestly hope this catches on because I would prefer it to the current system of having to manage a bunch of separate passwords (which currently are also saved on my phone)
this is only fine if you can trust your own phone and that there is no malicious apps doing something, I don't really trust only my password, same as I don't only trust my phone, thus I prefer 2FA for really secure things as tied combination, both factors have weakness
by mobile outlook you mean policies set up by admin which can be bypassed by mail client sandboxing mailbox from rest of the phone? just don't use official client if you are not comfortable with admin of your company having full access to your personal phone, though admin can block unofficial clients...
If an attacker can unlock your phone he already has access to your email.
This isn't any different than using a ubikey or a password manager no one who uses really secure passwords remembers them so there isn't a component of something you know any more in any case.
>The Authenticator app is available for iOS, Android, and Windows 10 Mobile, but regrettably, while the first two include the new feature, Microsoft has not seen fit to add it to the version of the software that runs on its own platform, citing low usage. The eternal chicken-and-egg situation of low usage both causing weak app support and being caused by weak app support continues to be something that Microsoft has little interest in fixing.
Is this really still surprising people? Hasn't the messaging that Windows Phone is a dead platform been loud and clear for years now? The still haven't released the current-gen Outlook client on it.
Nadella inherited Windows Phone at 6-15% in most markets.
His actions, and inactions sent it's market share to 0.+%.
AFAIK this feels like intentional sabotage to please Wall Street and a few vocal shareholders - the same people who wanted to kill/sell Bing, Xbox and even Surface.
Outrightly canceling WP would have cause a massive protest but strangling it and dropping it for "low usage?"...
Wow the comment thread on the original MSFT blog post (direct link: https://blogs.technet.microsoft.com/enterprisemobility/2017/...) is just painful. It's mostly a collection of people who use Windows on their phone crying out about the lack of support for Windows.
Microsoft won't support their own platform (phone) with this. If that's the case then why would any other developer write apps for Windows? Also, I thought the big push was for Universal Windows Platform (UWP) apps that ran on mobile, desktop/tablet, and Xbox. I can understand that you may not want to write a custom app for a platform with tiny market share but "big" Windows still has a lot of share.
"A few people have asked if this works with Windows Phone version Microsoft Authenticator. Windows Phone makes up <5% of the active users of our Authenticator Apps so we have prioritized getting this working with iOS and Android for now. If/When it becomes a big success on those high scale platforms, we will evaluate adding support for Windows Phone." [1] - Reasons never to buy a Windows Phone #387.
This seems to be _less_ secure. I noticed yesterday that my iPhone's Microsoft Authenticator app emitted at least three notifications to "Approve sign-in request...ABCDE".
I almost never log into my Microsoft LiveID account, the only identity that uses that app for 2-factor. I thought it was a little screwy, so largely ignored the first request. By the time the second and third notifications came in I had read the news about MSFT's move to go to a simple "Approve/Deny" single-factor. An attacker could just go through a list of LiveID's and try and authenticate. With a large enough list, a few folks will just hit "Approve", I'd wager. I doubt the app use any other factors like GPS or IP address. NB: There does seem to be a timeout.
i changed my MS accoutn password to 20characters just months ago and it works fine, so have no idea what they are talking about, it's not like dumb paypal which didn't allow me same password and cut it at 19
I wonder if this might have anything to do with pushing legal liability for breaches onto the user and/or reducing fallout from future hacks.
If Microsoft stores passwords (salted and hashed, of course) which are later stolen and cracked (for example due to something wrong with the way they handled hashing), then Microsoft could perhaps be on the hook for damages (I'm thinking in the US, at least). It could also potentially be a lot of users affected, which means bad press.
If Microsoft only uses a OTP app that runs on the user's device, then the responsibility to secure that device is on the user - it's up to them whether they use a PIN, password, PIN pattern, fingerprint or indeed nothing at all. Also, if a bad actor needs to gain access to a user's device to access their account, the bad press of hackers stealing thousands or millions of credentials is avoided.
39 comments
[ 6.4 ms ] story [ 88.5 ms ] threadUser-originated passwords can be socially engineered, or just plain guessed. They can be sniffed with a key-logger, or over a non-secure connection. You can steal password databases and run them against rainbow tables, or brute-force them GPU farms. Password re-use also means that you don't have to defeat Microsoft's security to get at the password, you just need to defeat the security of the weakest vendor where that password is used. Some people will even just straight-up tell you their password if you ask them.
Using an authenticator app to generate one-time passwords means there is no database of password hashes to be stolen and leaked, nothing for the user to remember, no password to re-use with weaker vendor, and nothing for an attacker to brute-force. Because the passwords are single-use, a key-logger is of limited value too.
It also reduces the attack surface down from any script-kiddie who can break the security of the weakest vendor, down to people who physically have access to your phone (or can get malware on to it).
Yes, anyone with access to your phone has access to your Outlook, but chances are anyone with access to your phone has that anyway, and your device is probably locked with TouchID or similar.
So, I agree this is weaker than two-factor, but I don't think that's the point.
1. Install a client cert/pairing token/SSH key/etc. onto each client device;
2. ask the user to configure a password, with a recommendation that that password be short and memorable rather than long and unwieldy;
3. either encrypt the device-credential with the user-password, or send the server the password to hash and store;
4. if the password challenge-response is on the server, have the server validate the device credential "before" or "outside of" accepting password-auth challenges (e.g. in the case of a client cert, validating the cert at the TLS level before the auth request can even reach the backend.)
In other words, systems isomorphic to the financial chip-and-PIN system: the chip is something you have, while the PIN—something you know—is only there to prevent robbers from using the chip, rather than to provide any cryptographic security.
- You can set a policy on password length/characters, making them hard to guess.
- You can use SSL, and with free SSL certificates this is even simpler to achieve.
- Defense against rainbow tables can be achieved through salted hashes, as long as the salt isn't public.
While passwords are not a cure-all solution they're still a valid solution.
Another way of tricking someone to give you their password: http://bash.org/?244321
And hard to remember, so users will write them down, lose or forget them, thus requiring costly and insecure password recovery mechanisms. It's not at all clear that passwords actually add any real security due to these issues.
You could argue that knowing your house is still secured by something you have (the key) and something you know (your address).
Mobile Outlook already has the ability to require a password on the phone.
This isn't any different than using a ubikey or a password manager no one who uses really secure passwords remembers them so there isn't a component of something you know any more in any case.
Is this really still surprising people? Hasn't the messaging that Windows Phone is a dead platform been loud and clear for years now? The still haven't released the current-gen Outlook client on it.
His actions, and inactions sent it's market share to 0.+%.
AFAIK this feels like intentional sabotage to please Wall Street and a few vocal shareholders - the same people who wanted to kill/sell Bing, Xbox and even Surface.
Outrightly canceling WP would have cause a massive protest but strangling it and dropping it for "low usage?"...
Microsoft won't support their own platform (phone) with this. If that's the case then why would any other developer write apps for Windows? Also, I thought the big push was for Universal Windows Platform (UWP) apps that ran on mobile, desktop/tablet, and Xbox. I can understand that you may not want to write a custom app for a platform with tiny market share but "big" Windows still has a lot of share.
This is a great example of how to erode trust.
[1]: https://blogs.technet.microsoft.com/enterprisemobility/2017/...
Why would any other developer write apps for windows if that were not the case either?
I'd bet that, if there's any answer for that, it will be a perfectly valid answer for your question too.
I almost never log into my Microsoft LiveID account, the only identity that uses that app for 2-factor. I thought it was a little screwy, so largely ignored the first request. By the time the second and third notifications came in I had read the news about MSFT's move to go to a simple "Approve/Deny" single-factor. An attacker could just go through a list of LiveID's and try and authenticate. With a large enough list, a few folks will just hit "Approve", I'd wager. I doubt the app use any other factors like GPS or IP address. NB: There does seem to be a timeout.
Or am I missing something here?
I've used 26+ character passwords for at least 2 years
[0]: http://csrc.nist.gov/archive/pki-twg/y2003/presentations/twg...
If Microsoft stores passwords (salted and hashed, of course) which are later stolen and cracked (for example due to something wrong with the way they handled hashing), then Microsoft could perhaps be on the hook for damages (I'm thinking in the US, at least). It could also potentially be a lot of users affected, which means bad press.
If Microsoft only uses a OTP app that runs on the user's device, then the responsibility to secure that device is on the user - it's up to them whether they use a PIN, password, PIN pattern, fingerprint or indeed nothing at all. Also, if a bad actor needs to gain access to a user's device to access their account, the bad press of hackers stealing thousands or millions of credentials is avoided.