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.
The usernames do not need to be part of the audit trail -- the unique URL identifies the site it came from. You know you your own logins, presumably, so it doesn't need to be there.
myaudithooks.com should not be centralized -- I 100% agree. You should just be able to put any old URL there. If I want my audit entries to go to my box, I absolutely should be able to.
You're right, some attacker could post bogus information if the know the url... however, the urls should be unique enough that they can't just be randomly "guessed" by an attacker. Another alternative is to provide a callback url, the way stripe does, so the service can "authenticate" the audit log entry before I consider it valid. For example, if I receive an audit log entry with id "abcd1234", I can hit http://mydogfriends.com/audit/abcd1234 to make sure it responds appropriately.
The idea isn't fully fleshed out yet, but I think it wouldn't take a lot of work to make it happen.
The really tricky bit is always figuring out how to apply the idea to the general public.
Where would all the users who find websites by typing domain names into Google ask mydogfriends.com to send their audit entries?
People running websites are also not necessarily technical -- often there was a techie involved during set up, but then it's just "apply the wordpress updates when it prompts you" and that's that. Support for audit trails needs to be built-in by default if it'll be widespread.
Interesting stuff, anyway. It's worthwhile to keep fleshing out the ideas and possible pathways.
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.