The first problem with myaudithooks.com is the vulnerability of the audit site, especially if this is a hosted service accepting login reports streaming from lots of different sites.

I know, the actual usernames/passwords aren't part of the audit trail.

Or... the passwords aren't. The usernames probably are, because otherwise how would this login report be linked to the right user?

So then think about what you could do with that data, if you cracked myaudithooks.com. For the users/services using it, you'd have a comprehensive list (likely with usenames) of all of the sites these users access regularly, probably mostly with the same weak/reused passwords.

Alternative: don't crack it, just ruin it. How is myaudithooks.com going to really lock down the API calls so that only mydogfriends.com can report login events to mydogfriends.com... Otherwise you could have script kiddies just throwing in lots of junk data for fun, or a malicious attempt to discredit a bank, competitor, etc. by convincing many of their users (via fake audit reports) that their accounts are cracked.

I do think the general idea is good, though -- just not centralized.

Login auditing is good. I always appreciate the extra bit of info when I SSH into a server and see "Last login: (timestamp) from (IP.host.blah)".

It's also hardly ever used.

I suspect some of the problem is that the timestamp bit would make sense to most users, but the source is more likely to be confusing for the general public. A raw IP address certainly won't be useful, and location is very scary if they don't know it's not exact and sometimes wrong ("it said last login from the next town over... where my ex lives!!!"), and that means support costs for false positives.