"The major reason is: why the $!@% was there any secret to steal in the first place?"
The answer is simple "user support", from a business prospective they had two choices, "keep the secret" or "not keep the secret". If they kept the secret then they could offer "user support" on certain frequently occuring events, if they did not their customers ended up with non functioning security which would cost the customer big bucks to sort out (ie buy a new token).
The real problem is which "person" in EMC/RSA decided to make this database available on machines with external access and did they have any choice.
The cynic in me thinks that the choice was for "business efficiency" reasons and was made by a "bottom line watcher" in a senior position.
It has been said that EMC/RSA had an "opt out" policy for those customers that wanted to store the "secrets" themselves.
However nobody has confirmed if this realy was an opt out or not....
A little thought excercise for you to mull over,
If you think about the business process flow around the manufacture and supply of tokens you will realise that "opting out" is an extra stage which incures both expense and risk for the company.
That is for all tokens,
1, Manufacture tokens and give them serial numbers.
2, Make blank entry in the DB for the new serial numbers.
3, Program "secret" into the token and put in DB.
4, Add token to inventory.
Then at some future point,
5, Recieve order for tokens.
6, Ship tokens to customer.
Now most companies operate a "returns" process, where by a customer can return an item for a valid reason such as the wrong parts were shipped. Importantly these returns usually go back into the inventory.
Now if the "secret" had been wiped from the DB on dispatch then the returned tokens would effectivly be "land fill" as the cost of reprograming would probably wipe the profit off the item (due to unpackaging and repackaging and ensuring correct DB updates were made).
So in theory the removal of the "secret" would happen at some point after the returns period.
Now... this removal of the data would be a risky process, in that as it's an exception to the normal process any error could result in the incorrect data being deleted ie that of another customer due to a "data entry error".
The easy solution would be to have two DB's a production DB which is effectivly write only from step 4 and a User Support DB that gets a copy of the details from the production DB at stage 6.
If the customer requests the "opt out" option the secret does not get coppied into the User Support DB.
Irrespective of if the customer "opted out" or not if they return the token it gets put back into inventory and the record in the User Support DB gets wiped.
As the production DB did not get wiped at any point stages 5&6 can be repeated with a different customer without any risk.
So on the lose assumption that a company worked on that sort of quite reasonable system, what would they do if a data breach occured became public knowledge?
A, What is the actual betting that they never actually removed the secrets from say the production DB only say from the User Support DB when a customer "opted out"?
B, What is the actual betting that the production DB was any better protected than the User Support DB?
C, What is the actual betting they don't know which DB the crackers got access to?
D, So the lack of info from them is due to the fact they don't want customers to know they never realy wiped the secrets, and don't know if they have been stolen or not.
Now compare the results from the hypothetical company above to the response of EMC/RSA...
As I said it' just a thought excercise to mull over.