last day (15 days later) » 

14:48
73
A: Can an identity provider impersonate me? (Can Facebook post Stack Overflow questions under my name?)

alloYes, they can. Simple answer: You authenticate in some way, usually via username and password, to your identity provider (what you call a "third-party login provider"). The bad admin can store the transmitted credentials and just re-use them. This attack does not depend on how the backend is imp...

Of course everything can be solved by a blockchain .. and then you have bigger privacy issues. Why would you need a blockchain for login history?
@usr-local-ΕΨΗΕΛΩΝ that is fine, until one realizes one would like to not make their login to x****.com public. And if a login can not be added to the chain, there is no reason to have one.
Maybe the blockchain entry could be encrypted/hashed so that you and xxx.com are the only ones who can audit the login
@akostadinov As I love to say, blockchain is a solution in search of a problem.
@akostadinov - we used to say every problem in computer science could be solved with an extra level of indirection - but that's passé - today we solve all problems with a blockchain ...
14:48
A blockchain consists of an unbounded number of layers of indirection, after all. (We used to call that a linked list)
WoJ
WoJ
@phyrfox: it depends where the F2A is checked. If is is at the authentication broker's then the problem is the same (the bad guy could also have control on the mechanism to approve the F2A check). If it is at the data provider's (the one who delegated the authentication to the broker) then yes, but I doubt someone would use an F2A here, the main purpose being to offload the authentication.
I don't understand... Normally in this situation you don't have an account on service A, that's why you use a token from service B in the first place
@MarioTrucco That's not true, many services allow you to create an account independently and then "link" it to your Facebook/Google/etc account.
@SeanBurton You are right. That wasn't the case I had in mind, but it's still a point. I will elaborate into an answer later
Storing login attempts on the blockchain would be dumb, but blockchain could actually be useful, because it breaks Zooko's triangle. If you register a human-meaningful name for your public key on a blockchain (e.g, Namecoin, or Ethereum's ENS), you can prove you own that name by signing for it with with your private key (using something like MetaMask, or a hardware wallet). You now have a decentralised authentication system.
14:48
@James_pic, too bad if your key is stolen, then you lose your account. Unlike gpg or even if you use plain password. Not a substitute for 2FA too. There is also OpenID if you want to control how things work for yourself. Blockchain inferior is any aspect.
@akostadinov How is gpg different? A lost GPG key is exactly as lost as a lost wallet key.
@James_pic, you can keep a revocation cert offline and use it if key is stolen or lost. You can use sub-keys, etc. Perhaps there can be some convention for revocation in a blockchain. But why the added complexity, what would be the benefits, privacy concerns, etc.?
@akostadinov The benefit is that you can associate a human-meaningful name with a public key, without the need for a trusted intermediary. In most other schemes that I know of, it's possible for a trusted individual or organisation to claim that a certificate belongs to james_pic, when it does not. You can come up with schemes where a cabal of these trusted individuals needs to collude to impersonate me (e.g, Byzantine paxos with public key signatures), but then that starts to look suspiciously like a blockchain.
@James_pic, maybe you need to read-up more about gpg. And about blockchain I even don't know where to start. But try imagining the whole thing from the ground up and soon you will see where the issues lie.
@akostadinov Last time I worked with GPG it used a "web of trust" approach, where you rely on the reputation of others who have signed a key to validate that its owner is who they say they are. High profile individuals are trust anchors, and if they're compromised, then trust is compromised. Does it now have a better approach that I'm not aware of?
14:48
@James_pic, this was your decision to use such trust approach. Exchanging keys without direct secure communication with the other party is a complicated thing. But the important question is, how exactly can blockchain make this easier and/or more secure. If you know such approach, then you may make a lot of money. My suggestion is to post your approach for review as a new question and collect feedback. There is no point in doing discussion in comments without any actual proposal.

last day (15 days later) »