Some programmer decided to filter characters and limit the length of a string. Honestly, it's reasonable. I know it's not the point but 16 ASCII chars can be used to create a secure windows password.
And people with passwords bigger than 16 chars are a corner case. HN has had top stories telling programmers not to care about corner cases or to assign a very low priority to them.
The passwords should be salted and then hashed. The hash produces the same length output no matter how long the input. Consequently length limitations are either UI/protocol limitations, or because salting and hashing is extremely poorly done. My money is on the latter.
I know. But yes I was thinking that the password still has to go through UIs (Web & Native), be sent over the network and read by the server and only than can it be hashed and compared to the stored hash.
I agree it sounds weird especially since I guess everything is done on top of .NET and JS. Neither of which is likely to suffer from buffer overflows nor would whatever protocols they use have problems transporting large strings with non-ASCII chars. And I don't any other technical problems that might cause.
But there has to be a reason. I guess it's possible someone was overzealous or screwed up. Maybe it was because it would be too hard to type it on an Xbox? Doesn't sound very plausible though.
I doubt that MS is doing password hashing wrong - it's not hard to begin with and they probably learned their lesson from the NT days when they implemented p.hashing poorly and it led to the NT passwords being easy to brute force.
> HN has had top stories telling programmers not to care about corner cases or to assign a very low priority to them.
That's because HN focuses on startups. Startups have extremely little time, money and resources. Microsoft has over 94,000 headcount.
Microsoft has extremely different expectations from startups. In fact, knowing just about anything about Microsoft's decades of history, you'd know just how much attention they pay to corner cases when it comes to backwards compatibility.
Another example: do startups spend much time preparing support for 50 different languages, including RTL, before a product release? Should Microsoft?
Advice you see on HN doesn't represent anything more than the current hip advice for startups. Certainly not how a multibillion dollar international corporation should design products.
But Apple is a multibillion dollar international corporation (more billions than MS) and they still famously cut corner cases.
If you go into every corner case, you'll never ship and I don't really think it's that practical/easy to keep adding people to a project to fix every corner case.
There's been more than one situation in which they ignored more than just corner cases in backwards compatibility: Windows Mobile -> WP7 -> WP8 and Internet Explorer come to mind. I don't know many examples but that might be because the only MS product I've actually owned in recent times was an XBox 360 (which went RRoD 2 yrs ago).
Also strictly speaking this isn't about backward compatibility, from the comments I've read here, you can still have the same windows password you had before. The password restrictions only apply to their online service (Live account or whatever they are calling it).
Comments
Some programmer decided to filter characters and limit the length of a string. Honestly, it's reasonable. I know it's not the point but 16 ASCII chars can be used to create a secure windows password.
And people with passwords bigger than 16 chars are a corner case. HN has had top stories telling programmers not to care about corner cases or to assign a very low priority to them.
In my opinion: "Nothing to see here, move along".
The passwords should be salted and then hashed. The hash produces the same length output no matter how long the input. Consequently length limitations are either UI/protocol limitations, or because salting and hashing is extremely poorly done. My money is on the latter.
I know. But yes I was thinking that the password still has to go through UIs (Web & Native), be sent over the network and read by the server and only than can it be hashed and compared to the stored hash.
I agree it sounds weird especially since I guess everything is done on top of .NET and JS. Neither of which is likely to suffer from buffer overflows nor would whatever protocols they use have problems transporting large strings with non-ASCII chars. And I don't any other technical problems that might cause.
But there has to be a reason. I guess it's possible someone was overzealous or screwed up. Maybe it was because it would be too hard to type it on an Xbox? Doesn't sound very plausible though.
I doubt that MS is doing password hashing wrong - it's not hard to begin with and they probably learned their lesson from the NT days when they implemented p.hashing poorly and it led to the NT passwords being easy to brute force.
> I doubt that MS is doing password hashing wrong
They have a long and storied history of doing just that. You can get a flavour from http://en.wikipedia.org/wiki/NTLM
Their hashing is most likely something defined to produce two parts from two 8 character chunks.
> HN has had top stories telling programmers not to care about corner cases or to assign a very low priority to them.
That's because HN focuses on startups. Startups have extremely little time, money and resources. Microsoft has over 94,000 headcount.
Microsoft has extremely different expectations from startups. In fact, knowing just about anything about Microsoft's decades of history, you'd know just how much attention they pay to corner cases when it comes to backwards compatibility.
Another example: do startups spend much time preparing support for 50 different languages, including RTL, before a product release? Should Microsoft?
Advice you see on HN doesn't represent anything more than the current hip advice for startups. Certainly not how a multibillion dollar international corporation should design products.
Good point.
But Apple is a multibillion dollar international corporation (more billions than MS) and they still famously cut corner cases.
If you go into every corner case, you'll never ship and I don't really think it's that practical/easy to keep adding people to a project to fix every corner case.
There's been more than one situation in which they ignored more than just corner cases in backwards compatibility: Windows Mobile -> WP7 -> WP8 and Internet Explorer come to mind. I don't know many examples but that might be because the only MS product I've actually owned in recent times was an XBox 360 (which went RRoD 2 yrs ago).
Also strictly speaking this isn't about backward compatibility, from the comments I've read here, you can still have the same windows password you had before. The password restrictions only apply to their online service (Live account or whatever they are calling it).