AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE will show up in the audit log whenever someone has a good token (or the seed values) and either fumbles or tries to guess the associated PIN. You'll get quite a few of these in normal use, simply because authorized users sometimes forget or mistype their PIN. If you see a lot of these against one single userid, chances are it will lock after "n" failed attempts and no harm is done. But if you see 1-2 of these per user and enumerating several of your users .. then you should take a closer look for sure. AUTH_PRINCIPAL_RESOLUTION / AUTH_ALIASES_NOT_FOUND will appear in the log if the userid that tries to log in does not exist. Again, you can expect a couple of these per day in normal operation, it is just a fact of life that users can't type their own names ... But if you get a lot of these, and especially if the username format is completely different than the userids in use, someone might be trying to guess your users from a phonebook or LinkedIn accounts. Take a closer look! Irrespective of the recent RSA breach though, there is one audit log entry that you should keep a close eye on: NEW_STATIC_PCODE_AUTH_SUCCESS shows up in the log whenever someone logs in with a static passcode. This means that the user has lost his token, or never had one, and that someone with ACE Admin privileges has assigned a static password instead. Yes, this is possible, and it basically turns two factor authentication into two-password authentication, while still everyone can claim to the auditors that "login goes via the SecurID server". There are legitimate emergencies for this kind of login, but it certainly is a dangerous option to have - if someone can smooth-talk your Helpdesk, they can get in, without needing a token. Considering the latter, you probably shouldn't worry all that much about what was or wasn't stolen in the recent RSA heist. But if you're not doing so yet, you certainly should check your ACE server audit log.
|
Daniel 385 Posts ISC Handler Mar 29th 2011 |
Thread locked Subscribe |
Mar 29th 2011 1 decade ago |
If you're going to check these logs (and you should, preferably automagically), I sugest you also check the default settings for automatically disabling a token.
Better yet, ask yourself how a list of usernames+tokenIDs got in the hands of a bad guys - maybe you should cross-check users to see when that list was stolen, and who has access to your RSA server. Remember an attacker needs the correct tuple of: Seed + TokenID + Username + Pin to authenticate.... Dom |
DomMcIntyreDeVitto 45 Posts |
Quote |
Mar 29th 2011 1 decade ago |
Is there a location where you received this information? I'd be interested in gathering further information on some other log entries we've been seeing.
Alex |
DomMcIntyreDeVitto 1 Posts |
Quote |
Mar 30th 2011 1 decade ago |
@Alex, the RSA Authentication Manager Admin Guide lists all possible audit messages for the ACE server, but admittedly the messages are not explained very well in there.
|
Daniel 385 Posts ISC Handler |
Quote |
Mar 30th 2011 1 decade ago |
"Good tokencode/bad PIN detected" is actually what "AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE" equates to on my log files.
|
Daniel 6 Posts |
Quote |
Mar 30th 2011 1 decade ago |
Can you refer me to the exact names of the document and the location in the document.
I have reviewed RSA AM 8.1 Admin Guide (using the link in RSA web site). It list of the log files generated but not the log messages Thanks in advance David |
Daniel 1 Posts |
Quote |
Nov 17th 2015 6 years ago |
Sign Up for Free or Log In to start participating in the conversation!