The hammer falls.

November 20, 2012

Never brag about your exploits on IRC

“Andrew Auernheimer, 26, of Fayetteville, Arkansas, was found guilty in federal court in New Jersey of one count of identity fraud and one count of conspiracy to access a computer without authorization.”

Given that the problem they found was that ATT wasn’t using any authentication, the conspiracy charge is quite the slap in the face.



I don’t share your greed…

October 16, 2012

…the only card I need is:

Here is an interesting concern for people with proximity card access control systems. Does your brand of reader have a default “backdoor” card ID that is considered valid?

You really should tear apart and check your card readers.


“SAP believes this case has gone on long enough”

August 7, 2012

SAP has settled (maybe) Oracle’s lawsuit over TomorrowNow.  The cost so far to SAP is US$306M.  A little advice:  Next time, make sure you use the –clairvoyant flag in your wget scripts!

So far, it appears that Oracle has successfully used the California legal system as an access control method.


The customer comes first at Oracle.

December 15, 2011

Even Oracle can screw up a PeopleSoft implementation.  If there was just a little more competition, say from a Tomorrow Now or a Rimini Street, would Oracle step up their game?


Blast from the past

September 1, 2011

Tomorrow Now less of a burden on SAP
What this means for Rimini Street, and the concept of entrapping your competitors for the purpose of civil litigation remains to be seen.  SAP already confessed liability, and this appears to  just mean less of a payout.

See also:  Oracle is Acting Rationally and Access Control in Real Life.


So when did RSA start shipping *your* replacement tokens?

June 7, 2011


It appears it was a seed compromise after all.  You need new tokens, and you need them months ago.  Cleartext token use is one way that someone could start gathering your tokens en masse.  An even scarier problem you are open to is a keylogger or other workstation compromise that has captured a token being used.

Pretend there was a keylogger trojan on one of your user’s workstations back in 2009.  Before it was removed/wiped/whatever, someone was able to capture a VPN login with username, tokencode, and PIN.  You know, “juser/908235123456”.  Oh, and for grins, the trojan also logged a decent timestamp:  “03/04/2009 17:34”.

Recovering the token based on this capture is a matter of grinding to find the appropriate seed.  The attacker just has to crank through each seed with nearby clock values (to account for drift), and id the seed that matches the tokencode generated…908235.  Now the attacker can simulate the correct token and pretend to be juser at will.

This breach not only put you in danger from the moment it happened (which is necessarily prior to when it was detected by RSA, which was before it  was reported by RSA…), it adds value to historical captures of SecurID authentications. Depending on when your tokens expire and how often you force PIN changes, that could be very, very bad.


Rogue CA risk.

March 30, 2011

What are you doing to mitigate the risk of untrustworthy certificate authorities?