4 ms·

Great idea! Exactly this is implemented across pretty much all "important" services in Sweden (Tax office, banks, pension funds, money transfers etc), it's call

Great idea! Exactly this is implemented across pretty much all "important" services in Sweden (Tax office, banks, pension funds, money transfers etc), it's called BankId: https://www.bankid.com/en/ https://www.bankid.com/en/ It's a great concept but currently somewhat limited to government and financial services, I would love to see something similar get good traction!

arnarbi 9y ago
BankId is not even close to this. It's a centrally managed PKI, which exists in many countries. This is another password=kdf(site data, master pwd) protocol.
- homakov 9y ago
  Not another... It's more flexible kdf(site data, consumer, scope, expiration, master pwd) protocol, allows to prevent many other attacks and replace OAuth all in one.
  - arnarbi 9y ago
    Why replace OAuth? That's an authorization protocol. Do you mean OpenId Connect? In any case, I strongly believe these things should be managed by user agents: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.
    - homakov 9y ago
      Check "change password" section for rotation of one profile to another. It's quite simple Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)
      - arnarbi 9y ago
        An update operation is one part of a solution. Are passwords versioned? You will eventually get into a state on some client where you have changed the pwd N times since last talking to a particular server. Does that client have to keep around N passwords to be able to update it? That defeats the purpose of rotation, which is to fully retire an old key. As for your example, you can do exactly the same thing with OAuth client assertions: https://tools.ietf.org/html/rfc7521 https://tools.ietf.org/html/rfc7521 OAuth implementations being buggy is a valid point, but why wouldn't the same apply to SL or any authz protocol?
        homakov 9y ago
        I can't understand first paragraph, especially "versioned" passwords. Every profile is result of generation, and you can change profile (manually or automatically) if you think it was compromised. With OAuth you add a lot of extra code in your app. Like storing client_id client_secret and you need grant dialogs etc. Have a look at this demo (any account with web version): https://securelogin.pw/#provider=http://facebook.com&client=http://locateMyFriends.com&scope=Share%3dFriends https://securelogin.pw/#provider=http://facebook.com&client=..., Locations With NO code any website could ask access to other provider. Little code on the server side needed. Granular permissions. Etc
        arnarbi 9y ago
        With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to generate the old key, which is used to sign the change request. If you've changed your password multiple times since you last spoke with that website, how do you know which old password to use. You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords. For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story. As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.
- TrickyRick 9y ago
  Ah, the resemblance I meant was more from a user's side, it's a smooth 2FA sign on solution with a single password.

arnarbi 9y ago

BankId is not even close to this. It's a centrally managed PKI, which exists in many countries. This is another password=kdf(site data, master pwd) protocol.

homakov 9y ago
Not another... It's more flexible kdf(site data, consumer, scope, expiration, master pwd) protocol, allows to prevent many other attacks and replace OAuth all in one.
- arnarbi 9y ago
  Why replace OAuth? That's an authorization protocol. Do you mean OpenId Connect? In any case, I strongly believe these things should be managed by user agents: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.
  - homakov 9y ago
    Check "change password" section for rotation of one profile to another. It's quite simple Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)
    - arnarbi 9y ago
      An update operation is one part of a solution. Are passwords versioned? You will eventually get into a state on some client where you have changed the pwd N times since last talking to a particular server. Does that client have to keep around N passwords to be able to update it? That defeats the purpose of rotation, which is to fully retire an old key. As for your example, you can do exactly the same thing with OAuth client assertions: https://tools.ietf.org/html/rfc7521 https://tools.ietf.org/html/rfc7521 OAuth implementations being buggy is a valid point, but why wouldn't the same apply to SL or any authz protocol?
      - homakov 9y ago
        I can't understand first paragraph, especially "versioned" passwords. Every profile is result of generation, and you can change profile (manually or automatically) if you think it was compromised. With OAuth you add a lot of extra code in your app. Like storing client_id client_secret and you need grant dialogs etc. Have a look at this demo (any account with web version): https://securelogin.pw/#provider=http://facebook.com&client=http://locateMyFriends.com&scope=Share%3dFriends https://securelogin.pw/#provider=http://facebook.com&client=..., Locations With NO code any website could ask access to other provider. Little code on the server side needed. Granular permissions. Etc
        arnarbi 9y ago
        With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to generate the old key, which is used to sign the change request. If you've changed your password multiple times since you last spoke with that website, how do you know which old password to use. You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords. For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story. As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.
TrickyRick 9y ago
Ah, the resemblance I meant was more from a user's side, it's a smooth 2FA sign on solution with a single password.