Is SlashID a Single Point Of Failure?
One question I have to answer frequently - is SlashID a Single Point of Failure (SPOF)? For example, here we are said to “have a significant SPOF”.
SlashID is a “centralized” service (just because there is no other SlashID around), so looks like “centralized” automatically means “SPOF”. How come?
First of all, we can “fail” in two ways - our server can go down, or it can be broken into or otherwise compromised. If we are down, you cannot login using SlashID, but you are not locked out of all your online accounts. You just use a “forgotten password” option on a website, and you should be able to login with a new password they send to you. So, if SlashID server is down, it will cause inconvenience, but it will not lock you out of your internet access. It will also not be a significant business continuity risk for the Relying Party, since their customers are still logging in.
If our server is compromised (including our secret keys), the attacker cannot get access to any data until they successfully guess your password. The problem is that now they can do it “offline”. So your protection is as strong as your password is - that’s why we require strong passwords when you register. Without our server being compromised, nobody can even try to guess your password - they will have to come to us to check every attempt, and we won’t be very helpful when we see them hit our server hundreds of times…
So we are “centralized”, but not really a “SPOF” - our failures don’t lead to catastrophic consequences, just to minor inconvenience if our server goes down, and increased risk (as opposed to total failure) if our server is completely compromised. There are ways to reduce or even eliminate this risk by turning SlashID into multiple unaffiliated servers which split the secret keys between them. This is something we will happily do in the future if we see the demand.