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

I changed my password at Charles Schwab to a longer one, and Quicken 2007 H&B no longer downloaded, but would give OL-332-A errors.

Called Schwab tech support, and the agent immediately asked what the length of my password was.

Turns out one can only use the first 8 (eight) alphanumerics of the "real" password in Quicken 2007 H&B's Password Vault.

Just in case anyone else has the same problem in the future.

Bob

Reply to
Bob Wang
Loading thread data ...

I don't have Q2007, and don't use Charles Schwab; but I'd like to encourage you and others to try to clarify this problem. I don't recall hearing of this before, and I think if it is an Intuit problem, they will be interested in fixing it. It's not clear from your explanation (or Schwab's) whether the problem is a Q2007 problem, a Schwab problem, or a combination of both.

Password criteria are normally supplied electronically by the fi to Intuit and passed to Quicken when you download.

Did you interpret Schwab to be saying that Q2007 could not handle more than an 8 character password? If so, aren't a lot of Q2007 users - even users not dealing with Schwab - going to be having this problem?

Or is it possible that Schwab has not made their password requirements correctly available to Intuit/Quicken.

Or ... ?

At least one user of a Quicken version earlier than Q2007 reported successfully using a 31 character password.

Are customers of other fi's besides Schwab not able to use passwords longer than 8 characters in Quicken in Q2007? In earlier Quicken versions?

Reply to
John Pollard

John:

I think the problem *is* specific to Charles Schwab.

My Chase, Citi, and State Farm Bank accounts have passwords longer than 8 characters, and they download just fine in Q2007 H&B.

However, I do have to confess that it was perversely enjoyable to have a tech support person instantaneously diagnose a problem ;-)

Bob

P.S. *31* character password! Holy flying fingers, Batman.

I don't have Q2007, and don't use Charles Schwab; but I'd like to encourage you and others to try to clarify this problem. I don't recall hearing of this before, and I think if it is an Intuit problem, they will be interested in fixing it. It's not clear from your explanation (or Schwab's) whether the problem is a Q2007 problem, a Schwab problem, or a combination of both.

Password criteria are normally supplied electronically by the fi to Intuit and passed to Quicken when you download.

Did you interpret Schwab to be saying that Q2007 could not handle more than an 8 character password? If so, aren't a lot of Q2007 users - even users not dealing with Schwab - going to be having this problem?

Or is it possible that Schwab has not made their password requirements correctly available to Intuit/Quicken.

Or ... ?

At least one user of a Quicken version earlier than Q2007 reported successfully using a 31 character password.

Are customers of other fi's besides Schwab not able to use passwords longer than 8 characters in Quicken in Q2007? In earlier Quicken versions?

Reply to
Bob Wang

I too am happy when a financial institution acknowledges a problem. :)

I just wasn't sure from your explanation, whether Schwab was saying the problem was theirs, or Quicken's.

(Yes, a 31 character password. And the poster was complaining that Quicken wouldn't handle the 32 characters that their fi had allowed.)

Reply to
John Pollard

"John Pollard" wrote in news:nxDkh.329711$1i1.77570 @attbi_s72:

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.

Reply to
Porter Smith

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.

Reply to
John Pollard

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.

Reply to
John Pollard

"John Pollard" wrote in news:R2Rkh.194805$aJ.3331 @attbi_s21:

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".

Reply to
Porter Smith

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 .

Reply to
Jay M Apple

"Jay M Apple" wrote in news:hJKdnatpQu2CpgnYnZ2dnUVZ snipped-for-privacy@comcast.com:

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.

Reply to
Porter Smith

I believe the problem is with Quicken 2007. I tried to enter a new password into my password vault and the dialog box where I'm typing my password stops at 10 characters.

Bryan

Porter Smith wrote:

Reply to
bsapen

Are you now able to enter your password and logon to E*TRADE?

Intuit indicates that this should not be a problem; that E*TRADE accepts passwords from 1 to 32 characters in length ... and that Quicken recognizes the same criteria for E*TRADE.

Reply to
John Pollard

Are you now able to enter your password and logon to E*TRADE?

Intuit indicates that this should not be a problem; that E*TRADE accepts passwords from 1 to 32 characters in length ... and that Quicken recognizes the same criteria for E*TRADE.

Reply to
John Pollard

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.