Workaround to get 952 when password in 10.00.FC9
Posted in 2009
The poster wanted IDS 10.00.FC9 to return error -952 (wrong password) rather than the generic -951, because many of their accounts are expired and users misread -951 as expiry; IBM refused, calling the merged message a deliberate security improvement. Respondents agreed hiding the distinction is safer against dictionary attacks, and suggested handling it in the application: on -951, check whether the account exists/is expired/locked and show an appropriate message, plus lockouts after N failures, or notify users of expiry/lockout via a separate daily report or email. No server-side tunable or fix was found.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Security, Permissions & Auditing
Hi everyone, i contacted IBM for a fix or a tunable solution to get error cod 952 when password is wrong, they said no to this, saying that its a improvement that they did, and they dont see the need to get back the change, this is not a solution for us. Actually we think they could do a tunable solution, like its a paremeter to let users create database they could do a solution for this. Currently im thinking what we can do to let users know when they input their password wrong. I was reading about PAM and LDAP, but i think a big change for our production. Do you have any idea, a workaround we could do for this?? The main idea is let the users when they input wrong password. Thanks in advanced.
> The main idea is let the users when they input wrong password. Oh lordy, this is a very bad idea! There is value in the -951 non-descript authentication failure message. Reason being: hackers using dictionary attacks against your DB server. If you return a message that indicates only a wrong password, you give a HUGE advantage to hackers, data-thieves, and the like. If they know they have a correct Login ID, but just the wrong password, they will break into your system much faster. I know this, I've had database servers that have been successfully hacked years ago. NOT a good thing. I would suggest only giving that specific of an authentication failure message (-951). Just my 2-cents. Jonathan B. Smaby Pomona College Administrative Information Systems Office on-campus extension: x18506 phone: (909) 621-8506 email: jonathan.smaby@pomona.edu -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of LYNKZ MIKE Sent: Wednesday, March 18, 2009 9:09 AM To: ids@iiug.org Subject: Workaround to get 952 when password in 10.00.FC9 [15211] Hi everyone, i contacted IBM for a fix or a tunable solution to get error cod 952 when password is wrong, they said no to this, saying that its a improvement that they did, and they dont see the need to get back the change, this is not a solution for us. Actually we think they could do a tunable solution, like its a paremeter to let users create database they could do a solution for this. Currently im thinking what we can do to let users know when they input their password wrong. I was reading about PAM and LDAP, but i think a big change for our production. Do you have any idea, a workaround we could do for this?? The main idea is let the users when they input wrong password. Thanks in advanced. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ------------------------------------------------------------- This message has been scanned by Postini anti-virus software.
My thoughts: The error you are getting, -952, is bad login id or password. Why not just tell your users exactly that: "Login failed. You may have mistyped your login id or your password. Please try again." Their login id they can see on screen as long as you don't clear the field, so once they check that, I'm sure most of your users are mostly smart enough to figure out that it must be that they fumble fingered their password. Trust your users, and tell management I said "It'll be OK." ;-) Art On Wed, Mar 18, 2009 at 12:08 PM, LYNKZ MIKE <yellr@telecom.com.co> wrote: > Hi everyone, i contacted IBM for a fix or a tunable solution to get error > cod > 952 when password is wrong, they said no to this, saying that its a > improvement that they did, and they dont see the need to get back the > change, > this is not a solution for us. Actually we think they could do a tunable > solution, like its a paremeter to let users create database they could do a > solution for this. > > Currently im thinking what we can do to let users know when they input > their > password wrong. I was reading about PAM and LDAP, but i think a big change > for > our production. Do you have any idea, a workaround we could do for this?? > > The main idea is let the users when they input wrong password. > > Thanks in advanced. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --00163631059dcb00ef046569e0a4
Hi Art, thanks for response, but a lot of user accounts are expireds, so, when users see error code 951 they thinks their accounts are expired when actually they typed wrong password, thats what its happening to us. I would like to have any idea to let application when users typed wrong password. Thanks a lot in advanced for help.
Then when the app gets the -951 check the account. If it doesn't exist, tell the user, if it is expired tell the user that, otherwise, if it's a valid and active account tell them it's a password problem. However, keep in mind the warnings about security and hackers. The less information you give a potential hacker, the better. If you do start giving specific messages, you should implement an additional anti-hack protection or two like blocking the ID for a time after N failed login attempts. Art On Wed, Mar 18, 2009 at 4:34 PM, LYNKZ MIKE <yellr@telecom.com.co> wrote: > Hi Art, thanks for response, but a lot of user accounts are expireds, so, > when > users see error code 951 they thinks their accounts are expired when > actually > they typed wrong password, thats what its happening to us. > > I would like to have any idea to let application when users typed wrong > password. > > Thanks a lot in advanced for help. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --001636426a0994ee0d04656bc765
Hi Art, thats what we have implemented here, we use AIX and one rule on O.S is block account after 3 inputs password wrong!! Thanks in advanced
Actually i was thinking, it could be a solution to let to know application when the account is expired, althougth this could be a security breach again, but wondering if this is possible?? Thanks in advanced
I handle user password expiration and self-lock-outs via a daily user report that goes to key I.T. support reps as well as a message to the individual user's Exchange email account. This saves us from having to pass specific authentication failure results to users, hackers, data-thieves, Sen. Barney Frank, Uncle Sam, and anyone else that wants to log in. Sort of like handling it on the back-end instead of the front-end. My daily report currently includes a message to the effect of: A) Your Password is about to expire in X days. B) Your Password has expired X days ago. C) Your account was placed on administrative lock due to exceeding allowed incorrect password attempts. My wish-list and desired enhancements would probably include: D) Your account was locked because you created a Giant SQL Cartesian Product in a recent query that brought the system to its knees. E) Your account was locked because all your outer joins used up sufficient system resources that brought down Informix and sent a pager alert at 3:00AM this morning. F) Your account was locked because you left yourself continuously logged for the past 3 weeks while holding table and row level locks in the system. G) Your account was locked because you're the typical programmer that lied to the CIO and blamed the Sys DBA's for your sloppy and leaky code that I spend the last week trouble-shooting for you. H) Your account was locked because you went whining to the HR department because of previous account notifications. But I doubt the Human Resources and Tech Committees would allow those changes... *SIGH* Jonathan B. Smaby Pomona College Administrative Information Systems Office on-campus extension: x18506 phone: (909) 621-8506 email: jonathan.smaby@pomona.edu -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of LYNKZ MIKE Sent: Wednesday, March 18, 2009 3:22 PM To: ids@iiug.org Subject: Re: Workaround to get 952 when password in 10.00.F [15224] Actually i was thinking, it could be a solution to let to know application when the account is expired, althougth this could be a security breach again, but wondering if this is possible?? Thanks in advanced ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ------------------------------------------------------------- This message has been scanned by Postini anti-virus software.