All of these points have inaccuracies, and I'll run through them one by one:
> For one, the identity string it generates for a site is static, and is the only thing need to identify/log you in. They never cover that this basically _IS_ a password. If you have a this static string, you have the password for that site.
The identity generated is a public key based on a private key in the identity. You do need one password, the master password for the identity on the device for an initial decryption to make the Challenge Response work.
> Further it sounds like the website operators also need to store these strings as plain text. I don't know how their rekeying method would work other wise.
What the website stores is a public key. Rekeying works via some other cryptographic methods to create new public keys. A server, presented with a previous public key and a new public key will replace the previous key with the new key. The new key can be confirmed as belonging to the previous identity, while not able to be regenerated by the identity without the rescue code. Full disclosure: Didn't really understand the math behind it, but that's the premise of the protocol. Securing that rescue code is extremely important and it should be stored separately from the identity (think at home with you birth certificate in the event your device is stolen while you are somewhere else).
> This means to me that if a websites database is stolen, then a person with that database could impersonate everyone immediately! No need to get a password cracker out at all.
The database only contains public keys of the user for the purpose of authentication. This table could theoretically be published, the compromise of the key does not compromise the identity nor allow a thief to log on (it would obviously not protect other information tied to the user like the email, address, etc. However, its a step in the right direction because it isn't a hash of a password to be rainbow tabled or the like).
> A website operator would need to completely disable all the existing keys, requiring everyone to rekey.
The compromise of all keys in the db would not compromise any identities. If a malicious actor changed identities to their identity, then there would definitely be problem, however, the operator could restore the public keys from backup and keep moving. This is not much different from passwords today, except that the user could no longer trust the password, no trust is lost in the public key.
> They have a global rekey method, but all their single site methods documented are very very manual and only possible if the site accepted you're old key.
This is valid. I'm imagining a perfect world with a correctly implemented spec. We can all work together to make it a reality.
> The global rekey method is also very scary to me. You need to visit a site for the rekey to happen. They state that after a rekey it will send your current and old key over. However how many keys will it send? What happens if I have to they N times because of different site data beaches. Will sites I haven't visited no longer be usable because their key is no longer available?
It would be semi-true that you would lose access in a world where software is the only intervening factor. The reality here is different: The public identity is string in the DB associated with the user. A website operator can have a user come in with their birth certificate and passport or whatever, verify a user, and change their public key in the database. This would be totally out of scope of the spec, not expected behavior, and potentially compromises perfect security, but the reality we live in is imperfect.
Everything, at some level, is going to come down to trust, and anyone with DB access can do anything anywhere anytime.
EDIT: I reread this again and realize what you are talking about is the string of the public key being stored, and potentially providing an avenue for an attacker to replace that string with their own identity in order to gain authorization of that user. I do think that is a risk, however, an attacker with DB access is probably not going to waste time impersonating users: they have access to the DB directly.
This would only be a problem in the instance a users data is encrypted and can only be decrypted by the user. So logging in as the user would grant some special way of seeing their data (though even here, if the server holds all the secrets, this isn't secure).
SQRL has an answer for this, as a private key can be stored with the SQRL identity to allow data to be accessed by the user who can also prove they have access to the identity. This would allow a server to reliably store sensitive information without worrying if the public key of a user got changed to allow a malicious actor to impersonate said user.
I can only imagine this being leveraged for medical records or financial transactions, but a way is built into the protocol.