Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

This RFC shall address the following two issues

  1. edit/update nodes owned by Anonymous Monk (AM)
  2. claim ownership of nodes initially generated by Anonymous Monk
using a simple unlock-phrase based and time-bound mechanism.

Current Situation

After hitting the create button, a node owned by AM cannot be updated anymore. This is obvious since several AMs cannot be distinguished from each other (AM#1 could edit node of AM#2).
A node created by AM cannot be claimed (automatically) by a regular registered user, though this can be useful. E.g., when forgetting to log-in, being at $work, etc. (Update) ... or other situations, see e.g. Can I adopt a node?.

Basic Approach

The basic idea is to present an unlock-phrase that can be used for a given node to editing and/or to claim ownership of this node. The unlock-phrase is presented after hitting the create-button. An AM who intents to update the given node or who later wants to claim ownership has to remember this unlock-phrase. Maybe the unlock-phrase can be saved as a cookie?

Usecase: Updating a Node owned by AM

When logged in as AM, presenting the unlock-phrase allows to edit the node. A new unlock-phrase is created after the update button has been hit. The option to edit a node owned by AM is time-restricted (e.g. 5 days). After this time, no further update is possible. The time window restriction makes it easy to protect old nodes owned by AM. Furthermore, it might reduce the PM servers load. Updating a node must not reset the time-window.

Usecase: Claiming Ownership of a Node owned by AM

During a time window of e.g. 5 days, a regular PM user, who is logged-in, sees an option to adopt a node that is currently owned by AM. Maybe this option can be switched on/off by means of CSS and/or Display Settings? If the user enters the correct unlock-phrase, the ownership is transferred. Since the node is now owned by someone else than AM, the option to transfer ownership vanishes.

Reputation and XP

I am not sure about that. Maybe reputation is transferred completely but not XP. So, XP changes while the node is being owned by AM goes to AMs account, while XP-changes after claiming the node go to the users account.

Implementation Considerations

It should be possible to implement this RFC without introducing changes to the database layout. The unlock-phrase could be created by hashing (e.g. MD5) a secret initial vector + the node-content + the node-ID + some other unique node-specific value. Then the digest is transformed into some human-readable unlock-phrase. Something along the idea implemented by Digest::BubbleBabble.
Since the node creation time is a known DB entry, the time-window can be computed/checked easily.

Update: I assumed, that the DB has no spare field left to store the hashed key-phrase. If it actually has, wonderful. Just generate a random unlock-phrase and store it's salted hash (e.g. bcrypt) for later validation.
In case there is no spare field left, the method above should work. Validating the unlock-phrase means re-calculating it and comparing it with the one presented by the user.

Drawback of this method: If the node is edited by a janitor, the unlock-phrase will change, making it impossible to edit/claim that node later on.

From a security point of view, the secret initial vector is the weak point (security by obscurity). If this is a constant value (e.g. hard-coded), an attacker that gets into possession of this value could hijack/modify every AM post within the time window. That could be alleviated by using a secret vector that changes daily (lookup-table or computed = f(creation time)). Ideally this vector would be an individual salt, but storing that would require an extra DB field.
Further conceivable counter-measures (unfortunately all of the security by obscurity kind): hash several rounds; get a seed from some internal DB fields (of given node) not visible outside; use a modified version of Digest::BubbleBabble; use another Digest::xxx; etc.
The point is to make it practically infeasible for an attacker to hijack an AM node.
An online brute-force attack seems unlikely taking the natural deliberate responsiveness of PM into account ... but adding a sleep 5; to the validation process should do no harm. Sure, an attacker could create a node and then try to reverse-engineer the process to generate an unlock-phrase using computational power available locally. So the process of generating the unlock-phrase should not be too obvious.

Time window (response to #919042): 5 days was a first guess, but I consider 5hours too short. If I come back one day later and want to update a node, than I need a bigger time window than 5 hours. In principle, it would be possible to have two time-restrictions: maybe 24 hours to claim a node and 48 hours to update a node?

[AM initial node] ---------(time window expired)--> [AM locked node ] | | | (valid unlock phrase to update node) | | | v | [AM updated node] --(time window expired)--> [AM locked node ] | | | ^ | | v | | | (valid unlock phrase to update node) | | (valid unlock phrase to claim ownership) | v [USER claimed node] (behaves like any regular user node)

Acknowledgments

This RFC has been refined during a short CB-discussion involving the feedback of tye and mr_mischief.


In reply to RFC: Updating and Claiming Ownership of Nodes initially created by Anonymous Monk by Perlbotics

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2024-03-29 09:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found