4 ms·

I'm fairly certain that they always truncated to the first 16 characters. About a year ago I had a 20 char password for my hotmail, and would happily enter it,

I'm fairly certain that they always truncated to the first 16 characters. About a year ago I had a 20 char password for my hotmail, and would happily enter it, but one day I was using some other input method (I think it was on my phone) and it stopped entering chars from 16 onwards. I was confused when it accepted my password, but then after some testing I realised what was happening. It just seems they are being more explicit about it now. It is quite an odd decision to make though.

dpark 14y ago
> It just seems they are being more explicit about it now. It is quite an odd decision to make though. Given a choice between hidden limitations and explicit limitations, I'd much rather have the explicit ones. At least then it's clear what you're getting. I'd prefer they eliminate the artificial restrictions entirely, of course. Disclosure: Microsoft employee
- olivier1664 14y ago
  What is freaking is that it may not be an "artificial restriction", but a VARCHAR(16) restriction caused by a plain-text storing. We certainly all have done this error: you create a database with the table "User" with the password in plain text. So VARCHAR, and humm, a max size... my password is 6 character long, but some user may go to 8, ok to be sure nobody will never complains, let's go for 16 characters. With some luck, your database truncate VARCHAR that are too long into VARCHAR(16) without notifying you. In this case, chance are nobody will notices there is a problem. I do not thing this is the current explanation for hotmail. But it is funny to see that it looks like a very basic error.
  - dpark 14y ago
    I seriously doubt that this is the case (though I have no visibility into Microsoft account auth). Most likely, there was some poor design choice years ago (such as the one you described) that has been corrected, but the effects its caused haven't been fixed through the codebase. e.g. I would not be surprised if the code contains something like this: struct user_auth { char username[64]; char pw[16]; // TODO: Allow longer passwords //... }; bool authenticate_user(user_auth* ua); This kind of code would limit passwords to 16 characters, but would be irrelevant to how passwords are currently hashed or stored.
air-lemming 14y ago
Actually, if this is the case, then it seems reasonable as a transitional step towards actually allowing longer than 16 character passwords. This way users will start entering the 16 characters of the password that is hashed (hopefully) and stored, then users won't enter their longer truncated password when longer passwords are allowed. However, this transitional step could be skipped with a truncated password flag that is set for all old passwords, and cleared for new passwords. Although, this would mark easier targets if the table is dumped through an SQL injection.

dpark 14y ago

> It just seems they are being more explicit about it now. It is quite an odd decision to make though. Given a choice between hidden limitations and explicit limitations, I'd much rather have the explicit ones. At least then it's clear what you're getting. I'd prefer they eliminate the artificial restrictions entirely, of course. Disclosure: Microsoft employee

olivier1664 14y ago
What is freaking is that it may not be an "artificial restriction", but a VARCHAR(16) restriction caused by a plain-text storing. We certainly all have done this error: you create a database with the table "User" with the password in plain text. So VARCHAR, and humm, a max size... my password is 6 character long, but some user may go to 8, ok to be sure nobody will never complains, let's go for 16 characters. With some luck, your database truncate VARCHAR that are too long into VARCHAR(16) without notifying you. In this case, chance are nobody will notices there is a problem. I do not thing this is the current explanation for hotmail. But it is funny to see that it looks like a very basic error.
- dpark 14y ago
  I seriously doubt that this is the case (though I have no visibility into Microsoft account auth). Most likely, there was some poor design choice years ago (such as the one you described) that has been corrected, but the effects its caused haven't been fixed through the codebase. e.g. I would not be surprised if the code contains something like this: struct user_auth { char username[64]; char pw[16]; // TODO: Allow longer passwords //... }; bool authenticate_user(user_auth* ua); This kind of code would limit passwords to 16 characters, but would be irrelevant to how passwords are currently hashed or stored.

air-lemming 14y ago

Actually, if this is the case, then it seems reasonable as a transitional step towards actually allowing longer than 16 character passwords. This way users will start entering the 16 characters of the password that is hashed (hopefully) and stored, then users won't enter their longer truncated password when longer passwords are allowed. However, this transitional step could be skipped with a truncated password flag that is set for all old passwords, and cleared for new passwords. Although, this would mark easier targets if the table is dumped through an SQL injection.