Difference between revisions of "Recovery"
From MgmtWiki
(Created page with "==Full Title or Meme== The problem of give users a continuing identity on a digital network. ==Context== Bayesian Identity Proofing provides the means for a collection o...") |
(→Context) |
||
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | The problem of | + | The problem of giving and maintaining a continuing identifier for a real-world person on a digital network. |
==Context== | ==Context== | ||
| − | [[ | + | The collection of [[User Private Information]] by a [[Data Controller]] now necessitates the ability [[Authentication|Authenticate]] the [[User]] under a wide range of challenges, like: |
| + | # Simplest of all the [[User]] needs to [[Authentication|Authenticate]] from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and [[Multi-factor Authentication|Alternate Authentication factors]] are lost or fail. | ||
| + | # More severe [[Recovery]] problems occur when the [[User]] has lost control of their account and needs it to be reset. The level of [[Authentication]] for these situation can be severely taxing to a user desperate for access to their accounts. | ||
| + | # When an [[Multi-factor Authentication|Authentication factor]] like an alternate email or phone number is compromised, insecure [[Recovery]] methods themselves become a means of attack, especially since factors like phone number were never intended to be secure.<ref>Lily Hay Newman, | ||
| + | ''PHONE NUMBERS WERE NEVER MEANT AS ID. NOW WE’RE ALL AT RISK'' (2018-08-25) Wired Magazine https://www.wired.com/story/phone-numbers-indentification-authentication</ref> | ||
| + | *Shane Weeden, IBM [https://www.ibm.com/blogs/sweeden/account-recovery-is-just-another-authentication-method/ Account Recovery is just another Authentication Method] | ||
==Problems== | ==Problems== | ||
| + | * Before the user can request a list of data that is held about them, or [[Redress]] for mistakes made by a [[Data Controller]] they must [[Authentication|Authenticate]] themselves to the data controller to assure that the [[Recovery]] process itself does not leak data. | ||
| + | * Before any [[Data Controller]] can report to the user about leakage of [[User Private Information]], they just have good contact information for the [[User]]. | ||
| + | * Before any [[Data Controller]] can allow access methods or factors to be changed on an account, they must be assured that this is not an attack. | ||
| + | * Recovery is a fertile place for attackers to take over user's accounts, particularly when a low security second factor, like SMS, is used for recovery. | ||
| + | * If the account the attacker subverts is an OpenID Provider (OP or [[IAP]]), the attacker can then move onto any Open ID Clients ([[RP]]s) that subscribe to that OP. | ||
==Solutions== | ==Solutions== | ||
| + | * As a part of creating a [[User Object]] to hold [[User Information]] any [[Site]] needs to first of all assure that they can contact the user. | ||
| + | * The two most common contact methods are email address and [[Smart Phone]] numbers. But such contact itself can become the vector for attack so any contact email must be recognizable and protected against spoofing by attackers. | ||
| + | * The downside to giving untrustworthy sites yet another means to reach out to users to capture their attention continues to occur<ref>Zack Whittaker, ''Twitter admits it used two-factor Phone Numbers and Emails for serving Targeted Ads.'' TechCrunch (2019-10-08) https://techcrunch.com/2019/10/08/twitter-admits-it-used-two-factor-phone-numbers-and-emails-for-targeted-advertising/</ref> | ||
==References== | ==References== | ||
| − | |||
[[Category:Glossary]] | [[Category:Glossary]] | ||
| + | [[Category:Identifier]] | ||
| + | [[Category:Recovery]] | ||
Revision as of 21:06, 26 October 2020
Full Title or Meme
The problem of giving and maintaining a continuing identifier for a real-world person on a digital network.
Context
The collection of User Private Information by a Data Controller now necessitates the ability Authenticate the User under a wide range of challenges, like:
- Simplest of all the User needs to Authenticate from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and Alternate Authentication factors are lost or fail.
- More severe Recovery problems occur when the User has lost control of their account and needs it to be reset. The level of Authentication for these situation can be severely taxing to a user desperate for access to their accounts.
- When an Authentication factor like an alternate email or phone number is compromised, insecure Recovery methods themselves become a means of attack, especially since factors like phone number were never intended to be secure.[1]
- Shane Weeden, IBM Account Recovery is just another Authentication Method
Problems
- Before the user can request a list of data that is held about them, or Redress for mistakes made by a Data Controller they must Authenticate themselves to the data controller to assure that the Recovery process itself does not leak data.
- Before any Data Controller can report to the user about leakage of User Private Information, they just have good contact information for the User.
- Before any Data Controller can allow access methods or factors to be changed on an account, they must be assured that this is not an attack.
- Recovery is a fertile place for attackers to take over user's accounts, particularly when a low security second factor, like SMS, is used for recovery.
- If the account the attacker subverts is an OpenID Provider (OP or IAP), the attacker can then move onto any Open ID Clients (RPs) that subscribe to that OP.
Solutions
- As a part of creating a User Object to hold User Information any Site needs to first of all assure that they can contact the user.
- The two most common contact methods are email address and Smart Phone numbers. But such contact itself can become the vector for attack so any contact email must be recognizable and protected against spoofing by attackers.
- The downside to giving untrustworthy sites yet another means to reach out to users to capture their attention continues to occur[2]
References
- ↑ Lily Hay Newman, PHONE NUMBERS WERE NEVER MEANT AS ID. NOW WE’RE ALL AT RISK (2018-08-25) Wired Magazine https://www.wired.com/story/phone-numbers-indentification-authentication
- ↑ Zack Whittaker, Twitter admits it used two-factor Phone Numbers and Emails for serving Targeted Ads. TechCrunch (2019-10-08) https://techcrunch.com/2019/10/08/twitter-admits-it-used-two-factor-phone-numbers-and-emails-for-targeted-advertising/
