Settings and activity
129 results found
-
Extend the "ban user" endpoint to accept "login" as an alternative to the already existing "user_id" 20 votes
Undeference
supported this idea
·
-
170 votes
An error occurred while saving the comment Undeference
supported this idea
·
-
83 votes
An error occurred while saving the comment Undeference
commented
It would be good if this also pinged moderators who aren't currently in chat if used by other moderators or the broadcaster.
Undeference
supported this idea
·
-
291 votesUndeference
supported this idea
·
-
20 votesUndeference
supported this idea
·
-
46 votesUndeference
supported this idea
·
-
41 votesUndeference
supported this idea
·
-
1 voteUndeference
shared this idea
·
-
52 votesUndeference
supported this idea
·
-
14 votesUndeference
supported this idea
·
-
95 votesUndeference
supported this idea
·
-
224 votes
An error occurred while saving the comment Undeference
commented
There are currently very many suggestions related to issues with password rules. The purpose of this suggestion is to supersede those complaints by recommending that Twitch specifically adopt the recommendations in NIST Special Publication 800-63B <https://pages.nist.gov/800-63-3/sp800-63b.html>.
The purpose is to not have any rules that make users jump through hoops without improving security. Specific recommendations include:
* Passwords should be at least 8 characters long and there should be no arbitrary maximum length (at least up to 64 characters)
* There should be no composition rules (e.g., rules like "must include a mix of letters and numbers")
* Ban passwords from previous breaches or that are trivially derived from common or easily guessable words or phrases
* Do not provide password hints
* Do no "knowledge-based" authentication (e.g., "mother's maiden name")
* Do not expire passwords without a reason
* Do not use SMS as a second factor for authentication (but any second factor is better than none)---
Selected quotes from appendix A:
"Humans… have only a limited ability to memorize complex, arbitrary secrets… online services have introduced… which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe."
"Password length has been found to be a primary factor in characterizing password strength… Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes."
"Research has shown… that users respond in very predictable ways to the requirements imposed by composition rules"
"Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases.""it is recommended that passwords chosen by users be compared against a [BANNED PHRASE] of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose."
"Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as [BANNED PHRASE], secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed."
Undeference
supported this idea
·
-
16 votesUndeference
supported this idea
·
-
3 votesUndeference
supported this idea
·
-
2 votesUndeference
supported this idea
·
-
4 votesUndeference
supported this idea
·
-
9 votesUndeference
supported this idea
·
-
3 votesUndeference
supported this idea
·
-
6 votesUndeference
supported this idea
·
-
3 votesUndeference
supported this idea
·
Currently, users can change their names once every 60 days and old user names are recycled after at least 6 months. In my experience, it is not uncommon for users to want to switch back to an old name but they have to wait 6+ months to do it. I suggest allowing a user to change their name back at any time within that 6 month period (like <https://twitch.uservoice.com/forums/310228-account-management-e-g-login-connections-pass/suggestions/42914982-revert-username-change>), bypassing the 60 day rename cooldown (but the cooldown would apply after renaming back).
I suggest limiting the 6 month grace period to names with some level of activity (i.e., while using that name). Specifically, the kind of "activity" I would consider are things where someone else taking the old name could confuse others, like adding friends or getting new followers. If this activity level has not been met, recycle the name after the 60 day cooldown (during which the user would still be able to revert the change).
In the same way, I have a number of suggestions to help with confusion after a user has changed names.
"Your channel URL will not redirect to your new name. You will need to update the URL anywhere you are using it." The old URL should redirect during the 6 month period (or for much longer, but maybe not forever, for partners). API requests for /helix/users?login=oldname should return successful responses with the login field as newname and perhaps an additional field indicating the matched oldname (so requests with multiple login parameters specified are not confused).
I suggest also showing in a users follows and friends lists the name that was used when the follow/friend was added, for at least the 6 month period.
Note:
Some people might say that some of these changes could help people intent on harassing others, but these suggestions are entirely about making name changes a more seamless transition in most cases. Renaming an account does not change its unique user identifier, friends, follows/followers, subscriptions/subscribers, some or all of which can potentially be used by harassers. The best option at this time in cases of harassment is to delete the account, after reporting everything to Twitch and law enforcement, if appropriate.