Has anyone had any problems with password corruption. We are currently using BO 4.1.1 on NT 4.0 against Oracle 7.3. We seem to be experiencing some sort of problem related to password corruption. We are using password checking with expiry. Our support group is getting a number of calls about expired password/disabled accounts. The number of calls leads us to believe that this isn’t a matter of our users being all thumbs or forgetful. I had heard of a password corruption/modification issue with DAS but not user entered passwords. Can anyone help???
Thanks
Vincent Cantarella
Applications Support Analyst
Barr Laboratories, Inc
Information Technology
(914) 348-6811 Fax (914) 348-8085
I don’t know about the expiring part, but there was a bug in versions of BO prior to (I think) 4.1.2. Basically, if the user had a password that was 8 characters long, and they entered it incorrectly, BO would actually CHANGE the user’s password (to what, I don’t know). I recommend upgrading to the current release, or disallow 8 character user passwords (good luck).
Jason Beard
AGD Consulting
==================================================================== Has anyone had any problems with password corruption. We are currently using BO 4.1.1 on NT 4.0 against Oracle 7.3. We seem to be experiencing some sort of problem related to password corruption. We are using password checking with expiry. Our support group is getting a number of calls about expired password/disabled accounts. The number of calls leads us to believe that this isn’t a matter of our users being all thumbs or forgetful. I had heard of a password corruption/modification issue with DAS but not user entered passwords. Can anyone help???
I don’t know about the expiring part, but there was a bug in versions of BO prior to (I think) 4.1.2. Basically, if the user had a password that was 8 characters long, and they entered it incorrectly, BO would actually CHANGE the user’s password (to what, I don’t know). I recommend upgrading to the current release, or disallow 8 character user passwords (good luck).
Jason’s 100% on the money. The expiration part comes simply because users no longer know their “changed” password and enter it incorrectly 3 times (assuming a standard password expiration configuration). If upgrading is not a readily feasible thing and you are in Oracle, you can use a trigger to stop the offensive behavior. The trigger, basically intercepts the statement in question and does not perform the update it requests. Note that this ABSOLUTELY DOES NOT IN ANY WAY, SHAPE, OR FORM alter normal password change/expiration/invalidation functionality. I’ve sent this before to the list, but I’ll repeat it here for your usage. Note that you will need to change “repository” to the table owner for obj_m_actor in your particular environment.
FYI,
Bob Molby
GE Lighting
–
– Temporary trigger to patch issue with Business Objects – intermittently altering passwords if they are entered – incorrectly
create or replace trigger repository.obj_m_actor_trg
before update on repository.obj_m_actor
for each row
begin
if :new.m_actor_n_type = 16 then
if (:new.m_actor_n_status = :old.m_actor_n_status + 127 and
:new.m_actor_n_cntdown = 0 and
:old.m_actor_n_cntdown <> 0) or
(:new.m_actor_n_status = :old.m_actor_n_status and
:new.m_actor_n_cntdown = :old.m_actor_n_cntdown+1) then :new.m_actor_c_password := :old.m_actor_c_password; end if;
end if;
end;
/
you are right. I have just tested this with BO 4.1 and 4.1.3, and it’s only happening in BO 4.1, and with 8 characters length. The impact is, that after the first wrong password was entered, BO adds the word “group” to the password.
e.g. Password was “12345678” before, and “12345678group” after.
Maybe you wonder how I know that, but there is a quite usefull freeware tool named Snadboy’s Revelation (www.snadboy.com) which decodes every windows encrypted password.
Hope that helps,
Mathias
From: Jason Beard[SMTP:Jason_Beard@SEAGRAM.COM]
Vincent,
I don’t know about the expiring part, but there was a bug in versions of BO prior to (I think) 4.1.2. Basically, if the user had a password
that was 8 characters long, and they entered it incorrectly, BO would actually CHANGE the user’s password (to what, I don’t know). I recommend upgrading to the current release, or disallow 8 character user passwords (good luck).
Jason Beard
AGD Consulting
You may want to up the number of Login attempts. Note that it doesn’t matter “where” failed logins originate from. So, imagine the following scenario.
I walk over to another users desk and login to show them something. I log out and go back to my desk.
They launch BO and enter their password, and fail to get in.
They re-type their password and hit enter… and it fails yet again.
On closer examination, they see that MY id was the last used, and they successfully login after changing to their username/password.
I go to my desk and enter my password, not noticing CAPS-LOCK was on… and now I’m locked out, though I have only failed to login correctly once.
The strikes are consecutive, regardless of origination. Upping the limit to something like 5-10 usually solves this issue.
To avoid this you could always delete the local *.lsi file after you worked from a different PC, which will force the user to enter a username next time they log in to BO Full Client.
I’ll try upping the number of attempts, but I don’t think this is user error. Especially because it happened to my PUBLISHER ID.
Our lockout rate went from 1-2 a day to 10-15 (out of about 400 users). Also, the problem seems more serious for certain users - the system acts as if their password is changed every morning - so three strikes and they’re out, but they swear they’re typing in the password they created the previous morning (some of these folks have been using InfoView for a year, so I tend to believe them. )
Deleting and recreating the ID seems to be a solution for the users with persistent problems, but its a real bummer for the customers when they’re locked out for no reason.
Capture the Encrypted passwords both before and after they fail. See if the Encrypted information is the same. If not, then it could be a regression… but I have yet to see this occur.
Additionally, this problem ONLY occurred when the passwords were EXACTLY 8 characters in length, so people with 7 or 9 were not affected.
After the individuals have password issues, do they choose the SAME password, or a different one? I find it odd that “re-creating” the userid would fix it… since that was not the case with the 4.x issue.
(BOB member since 2002-08-15)
(BOB member since 2002-06-20)