Anyone can invent any new methodology or technology to provide protection and security. For SecurID's case, it's the compromised servers that is the root of the issue instead of the SecurID authentication itself. You can create some new authentication or whatever protection mechanism but it relies on a server. All it needs is the server to be compromised yet again to see the same issues re-surfacing.
What RSA and SecurID inventor should do is to really look into securing the backend first as the main issue have always been insecure servers holding really important information in a highly insecure and careless way.
Ensure proper administration, C2 auditing enabled and reviewing of logs , encryption of information on all servers, assignment of rights and roles, seperated domains so that if a small domain of secured data gets compromised, it won't spread the impact across and finally re-evaluate your servers and staff efficiency frequently and conduct frequent penetration testing.
Data encrypted on databases on the backend should usually be done whereby an encryption secret key is responsible for a small small group of data it needs to be secured. So in an event of an attack, a compromised key would not compromise other keys (if the keys are secure de-linked and made unpredictable from one another).
The master key for encryption should be made up of more than 2 person's encryption secret key (bosses holds the secret keys). Imagine it's like a nuclear launch silo where you need many keys to be turned together to launch a nuclear missile. This would give more security. The master keys should be seperated from each other whereby if one key is compromised, it doesn't affect the others and can be regenerated
Last but not least, make sure the roles and administrative privileges are properly administered whereby power is not consolidated in one person's hand.
