Truncate Charles Schwab Password at 8 (eight) characters for Quicken 2007 H&B Password Vault

Posted by John Pollard on December 28, 2006, 10:05 am

Please log in for more thread options

Porter Smith wrote:

> I had a similar problem when I was switched from

> HarrisDirect to E*TRADE. It turns out that Intuit

> prevalidates the userid and password before sending it to

> the FI for validation. For example if a particlar FI uses

> your SSN as the userId and you specify a 5 digit nubmer,

> Intuit knows it can't be valid and gives you an error. In

> my case my password was 6 characters -- perfectly legal

> when I was with Harris, and "grandfathered" in when I

> moved to E*TRADE. But E*TRADE requires a minimum length

> of 8 characters. So when Intuit saw my 6 character

> password it "knew" it couldn't be valid for E*TRADE and

> never bothered to ask; It just gave me an error.

Thanks for pointing this out; I had never thought of it before.

But my interpretation of the cause of the problem - and the
solution - is different than yours. It is the financial
institution's responsibility to supply Intuit with their
password requirements; and it does not seem reasonable to expect
Quicken to carry "grandfathered" exceptions to those
requirements. If an fi elects to allow some users to have 6
character passwords, while requiring other users to have 8
character passwords, they should not tell Intuit/Quicken that
they require 8 character passwords.

--
John Pollard
First initial underscore Last name at mchsi dot com
Please reply to newsgroup

Posted by John Pollard on December 28, 2006, 10:05 am

Please log in for more thread options

Porter Smith wrote:

> I had a similar problem when I was switched from

> HarrisDirect to E*TRADE. It turns out that Intuit

> prevalidates the userid and password before sending it to

> the FI for validation. For example if a particlar FI uses

> your SSN as the userId and you specify a 5 digit nubmer,

> Intuit knows it can't be valid and gives you an error. In

> my case my password was 6 characters -- perfectly legal

> when I was with Harris, and "grandfathered" in when I

> moved to E*TRADE. But E*TRADE requires a minimum length

> of 8 characters. So when Intuit saw my 6 character

> password it "knew" it couldn't be valid for E*TRADE and

> never bothered to ask; It just gave me an error.

Posted by Porter Smith on December 28, 2006, 11:07 am

Please log in for more thread options

@attbi_s21:

> But my interpretation of the cause of the problem - and the

> solution - is different than yours. It is the financial

> institution's responsibility to supply Intuit with their

> password requirements; and it does not seem reasonable to expect

> Quicken to carry "grandfathered" exceptions to those

> requirements. If an fi elects to allow some users to have 6

> character passwords, while requiring other users to have 8

> character passwords, they should not tell Intuit/Quicken that

> they require 8 character passwords.

Absolutely. I had a nice chat with E*TRADE's tech folks about this. It
turns out that when they bought out HarrisDirect, they were not told of
these grandfathered short passwords, because HarrisDirect wasn't told
when they bought out CSFBdirect which hadn't been told when they bought
out dljDirect which allowed short passwords when I set up my account in
1996.

And since the password database is encrypted, there is no way to know if
any are "illegal".

Posted by Jay M Apple on December 28, 2006, 4:49 pm

Please log in for more thread options

> >>>>>>>>>>>>>>>>>>> SNIP>

> And since the password database is encrypted, there is no way to know if

> any are "illegal".

Beg to differ. Even if passwords in database encrypted, software validating
passwords entered in login screen can check on compliance of the entered
password with new standards before even getting the password in the
database.

We did it a couple of times when strengthening access to corporate data. Of
course there were all kinds of notices sent to users and/or splattered all
over login screen concerning the imminent change to a more secure
userID/password environment. After the announced effective date any user
that entered a noncompliant but at-the-time valid password was directed to a
screen where they could set up a new AND compliant password. Ditto for
userIDs. Once task was accomplished, users were returned to expected paths.

Ah, sweet memories of plugging security holes and soothing ruffled feathers
of "important" users....

Jay
.

Posted by Porter Smith on December 28, 2006, 11:15 pm

Please log in for more thread options

>> >>>>>>>>>>>>>>>>>>> SNIP>

>> And since the password database is encrypted, there is no way to know

>> if any are "illegal".

> Beg to differ. Even if passwords in database encrypted, software

> validating passwords entered in login screen can check on compliance

> of the entered password with new standards before even getting the

> password in the database.

My point was that if you have database of encrypted passwords, there is no
way of determining which of them are now illegal so the owners can be
notified. As you mentioned you have to trap them on the fly as the users
enter them.