3G/ 25 Billion Password Compromised - Preventing Account Takeover Using Open ID - SSE

From IIW

25 Billion Password Compromised - Preventing Account Takeover Using Open ID


Session Convener: Tom Sato Notes-taker(s): Tom Sato

Tags / links to resources / technology discussed, related to this session: Guide to Shared Signals

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


1. What is SSE

  1. Shared Signal and Events is a communication framework for two parties to share status and security alerts to protect digital identity
  2. Transmitter and Receiver establish secure and continuous communication line starting is OAuth handshake.
  3. It’s a secure Webhook so that transmitting IDP can let receiver, usually webapp that after login authentication, should IDP find security breach like password compromise, it can send security warning during session or even out of session.
  4. SSE has two sets of Security Event Token (SET) specification CAEP and RISC.

2. My idea is to two parties, usually two IDPs to share security alerts when IDP-1 end user finds password compromise and changes the password and let IDP-2 know that this password has been deleted and remediation is necessary.

  1. Issue 1. In order to make certain that IDP-1’s end users’ password is the same as IDP-2’s, IDP-1 needs to send a password in plain text, in order to verify that deleted password at IDP-1 is the same as IDP-2.
  2. Sending plain text password, even if it was deleted in plain text is a bad idea and compliance and privacy policy would not allow this to happen.

3. To do this, my idea is to create a verification token out of password that is obfuscated and encrypted using a key that is supplied by middleman. Because of obfuscation, it can’t be decrypted back to the original password. If the obfuscation and the encryption is done by same key and method, then IDP-1 can send this verification token to IDP-2 and comparison can be made.


  • Why do you need a token used as a key? Why not use industry standards hashing mechanism instead of a token?
  • IDP-1 may not have the deleted password in plain text to convert to verification token.
  • Do you have to store the verification token at IDP-2 until the end user actually make a login?
  • Why it is important to check both the user ID and the password?
  • How a password comparison can be made secure and privacy preserving?
Retrieved from "https://iiw.identitycommons.net/index.php?title=3G/_25_Billion_Password_Compromised_-_Preventing_Account_Takeover_Using_Open_ID_-_SSE&oldid=24212"