I actually emailed my credit union, pleading for them to increase their 10 character limit to something reasonable, and got a response saying that the way their database handles passwords made it impossible. Needless to say, I found that to be even more disconcerting than the existence of the character limit.
Don't worry too much about it. It's vastly more likely that it's actually their change policies that make the increase impossible.
What technical reasons are there to have low maximum password lengths?
101–110 of 128 posts
Re: What technical reasons are there to have low maximum password lengths?
#102Re: What technical reasons are there to have low maximum password lengths?
#103I actually emailed my credit union, pleading for them to increase their 10 character limit to something reasonable, and got a response saying that the way their database handles passwords made it impossible. Needless to say, I found that to be even more disconcerting than the existence of the character limit.
Re: What technical reasons are there to have low maximum password lengths?
#104Earlier quoted context omitted.
May I ask what bank you bank with?
All UK financial institutions I have used do this: Nationwide, Barclay's, Natwest (RBS).
Barclays for example allows you to log in with this plus a separate pass code, but you can't do much damage without using a chip and pin reader that will give you an 8 digit one time pad too (alternatively they now let you use a mobile app to generate the one time pads)
E.g. you can't do transfers to recipients you haven't specifically saved for future payments, for example, without entering your pin, the account number and amount into your key generator and entering the resulting code into online banking.
Re: What technical reasons are there to have low maximum password lengths?
#105Earlier quoted context omitted.
No; this is effectively the same as doing no hashing at all. If your database gets stolen, people can replay the "hashed" passwords from it to the server, without having to hash them themselves.
Couldn't you solve that by hashing it again on the sever?
Also please correct me if I'm wrong.
Re: What technical reasons are there to have low maximum password lengths?
#106Re: What technical reasons are there to have low maximum password lengths?
#107Earlier quoted context omitted.
All UK financial institutions I have used do this: Nationwide, Barclay's, Natwest (RBS).
Which is one of the reasons I do not use online banking!
They don't allow you only log in with two characters from your password like that, you also need a passcode or a one time pad generated with a chip and pin reader, and for transfers to accounts you haven't previously transferred money to and indicated you want to save for future use, you also need to enter your pin, amount and target account into the reader to get a code to enter into online banking to do the transfer.
Re: What technical reasons are there to have low maximum password lengths?
#108Wow what a dumb question obviously the OP has very little experience in dealing with real people, probably one of those code monkeys disconnected from the real world. Tune out of World of Warcraft, turn off your Xbox and think for a second: If people could choose long passwords with special characters how could our customer support reps read them back to the users in case they loose it? How could they check them on t…
Re: What technical reasons are there to have low maximum password lengths?
#109Earlier quoted context omitted.
Couldn't you solve that by hashing it again on the sever?
I'm not sure about the added security benefit. Basically the only additional security is if someone gains access to your server they can't capture plain text passwords anymore but once someone gains access all bets are off and they might as well just switch out the Javascript. In any case you should run a strong hashing algorithm like bcrypt with a salt and oh I don't know 1000 iterations? Also last time I tried some…
Re: What technical reasons are there to have low maximum password lengths?
#110Earlier quoted context omitted.
I'm not sure about the added security benefit. Basically the only additional security is if someone gains access to your server they can't capture plain text passwords anymore but once someone gains access all bets are off and they might as well just switch out the Javascript. In any case you should run a strong hashing algorithm like bcrypt with a salt and oh I don't know 1000 iterations? Also last time I tried some…
The added security benefit of server-side hashing is the same as if plain text passwords are sent, to prevent knowledge of the authentication secret if the database contents are disclosed to malicious third parties. The client side hash of the password is only to ensure that a fixed length secret is sent and subsequently processed, to avoid DoS attacks on the server.