Jump to content

Wikipedia talk:Wikipedia Signpost/2007-05-14/Committed identity

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

April 8, 2014

[edit]

This page is tagged as out of date, and there's a recommendation from Feb 2014 to only use cryptographic algorighms which are considered strong. Does anyone know if there are instructions anywhere for how to do this? Or any plans to update this page? Or any change to the recommendation -- perhaps now that we're on a secure server, it's not as crucial? 08:58, 8 April 2014 (UTC)

Because this was part of a dated edition of the "Wikimedia Signpost," it would be inappropriate to edit the body of this page. However, it would be entirely appropriate to create a new information page about committed identities that is up-to-date. It should probably be named Wikipedia:Committed identity/2014 draft or something like that. Once it is created and accepted by the community, Wikipedia:Committed identity can be deleted and the new page moved into its place. Shortcuts listed here (e.g. WP:CID) would need to be adjusted and hatnotes would need to be added to the top of both the Signpost article and the new Committed identity page.
You may be asking "but why not just edit Wikipedia:Committed identity "in place," why bother with a draft? The answer is that there are too many incoming links to Wikipedia:Committed identity and it would be a bad idea to have people clicking on those links see a draft-in-progress. davidwr/(talk)/(contribs) 03:00, 10 April 2014 (UTC)[reply]

Draft for "Committed identity" proposal at Draft:Wikipedia:Committed identity

[edit]

I had started a rough draft of a page that could be considered an actual policy for Wikipedia:Committed identity. Any help with this task is welcome. Steel1943 (talk) 19:53, 25 May 2015 (UTC)[reply]

This article was published before I'd even started editing Wikipedia (before, indeed many did). I see this because it is on my mass-issue watchlist, which I'm not entirely sure isn't unique, so I'd advise you try to bring this up elsewhere (village pump?). ResMar 05:52, 26 May 2015 (UTC)[reply]
Addendum:  Steel1943:. ResMar 05:52, 26 May 2015 (UTC)[reply]

Making this more secure

[edit]

Issues

[edit]

This feature has great potential and I think this could be very useful. However, while following the advice "[the string should] contain at least 15 characters and include unique information that only the account holder would know" would make it impossible to brute-force it by guessing random characters, it still has a number of security holes:

  • If someone has a general idea of what it could be, it could narrow the possibilities tremendously. For example, the example given in the article that says to change "Hewey, Dewey and Louie, October 17, 1937." to "Hewey October Dewey 17 Louie 1937. Egg salad is murder!" could still be brute-forced if someone knows the user's family members and has a powerful enough computer.
  • In the case that someone has a number of ideas, they would easily be able to verify whether one is correct.
  • Many users might not follow this advice and choose an insecure string, which would mean it could be brute-forced by guessing random characters
  • Vulnerable to repeat attacks: if an attacker reads the sent folder of someone's email, they can send the same code to Wikipedia and it would be impossible to determine who is the attacker and who is the legitimate user
  • It would involve sending the string to the Wikipedia administrators. A good string would be something nobody else knows, and I would assume that many of those things are not chosen because the user isn't comfortable with sharing that with the administrators.

While these methods take a lot of effort, there are millions of people who use Wikipedia, and if just one black-hat hacking group managed to compromise an interface administrator's account they could have Wikipedia steal everyone's passwords and install malware.

Proposed proccess

[edit]

Here is a different process that I propose:

Setting the secret

[edit]
  1. The user comes up with a secret string and gets the SHA512 hash of the string "REFERENCE/<username>/" plus the secret string, such as "REFERENCE/User:DonaldDuck1/Hewey October Dewey 17 Louie 1937. Egg salad is murder!".
  2. They then email this to the Wikimedia foundation, and they pepper the hash with a secret key only Wikipedia knows, then send it back to the user
  3. The user adds this to their usercard

Recovering an account

[edit]
  1. The user takes the hash of "<random number>/<username>/<secret string>", for example "12345678/User:DonaldDuck1/Hewey October Dewey 17 Louie 1937. Egg salad is murder!".
  2. They then email this to the Wikimedia foundation. If the random number has been used before or it is the wrong username, they ignore it.
  3. If the peppered secret key (originally sent by the user) is equal to the string that was just emailed, this is the correct secret.

Automating this process

[edit]

This is very cumbersome for both the user and the Wikimedia foundation. However it can easily be added as a [[Wikipedia:I will make a proof-of-concept script if this generates enough attention. Anonymous from Stack Overflow (talk) 18:42, 13 December 2021 (UTC)[reply]

Making this more robust

[edit]

This is an attempt to improve the process, as I find mine is now broken. I realise this talk page isn't structured the way most are so hopefully I'm makinng edits the right way? Please just delete what's not needed. -- Silicosaur'us 12:24, 13 August 2023 (UTC)[reply]

Issues

[edit]
  1. When the secret is used, something needs to be done to mark it as being used, and then to replace it.
    • Peppering the secret with the result of an S/KEY output would assist. The disadvantage is increased complexity.
  2. Users who fail to store their secret are potentially worse off than those who don't bother using the scheme.
    • Advice could be given, such as: including in the public part of the text a hint as to where the secret bit was stored.
    • Advice could be given, for the user to put an expiry time on the protection.