Difference between revisions of "Recovery"
From MgmtWiki
(→Full Title or Meme) |
|||
| Line 4: | Line 4: | ||
==Context== | ==Context== | ||
| − | [[ | + | The collection of [[Use 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 sever [[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 a [[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> | ||
==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 | ||
==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. | ||
| + | |||
==References== | ==References== | ||
Revision as of 10:58, 1 September 2018
Full Title or Meme
The problem of giving and maintaining a continuing identity for a real-world person on a digital network.
Context
The collection of Use 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 sever 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 a 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]
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
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.
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
