|
|
|
@ -531,33 +531,33 @@ solution was found.
|
|
|
|
|
|
|
|
|
|
### Forgotten password
|
|
|
|
|
|
|
|
|
|
With authentication and some sort of dealing with passwords is related problem
|
|
|
|
|
with forgotten passwords. People easily forget them and there has to be some
|
|
|
|
|
kind of mechanism to retrieve new password or change old one. Problem is it
|
|
|
|
|
cannot be done in totally secure way but we can at least come quite close to it.
|
|
|
|
|
But lets start from the beginning there are ways to handle that which are
|
|
|
|
|
absolutely not secure and recommendable, for example sending old password
|
|
|
|
|
through email. Better solution but still not secure is to generate new one and
|
|
|
|
|
With authentication and some sort of dealing with passwords is related a problem
|
|
|
|
|
with forgotten credentials, especilly passwords. People easily forget them and
|
|
|
|
|
there has to be some kind of mechanism to retrieve a new password or change the
|
|
|
|
|
old one. Problem is that it cannot be done in totally secure way, but we can at
|
|
|
|
|
least come quite close to it. First, there are absolutely not secure and
|
|
|
|
|
recommendable ways to handle that, for example sending the old password through
|
|
|
|
|
email. A better, but still not secure solution is to generate a new one and
|
|
|
|
|
again send it through email. This solution was provided in CodEx, users had to
|
|
|
|
|
write email to administrator who generated new password and sent it back to
|
|
|
|
|
sender. This simple solution could be also automated but administrator had quite
|
|
|
|
|
a big control over whole process which might come in handy there could be some
|
|
|
|
|
additional checkups for example, but on the other hand it can be quite time
|
|
|
|
|
consuming.
|
|
|
|
|
|
|
|
|
|
Probably the best solution which is quite used and fairly secure is following.
|
|
|
|
|
Lets consider only case in which all users have to fill email addresses into
|
|
|
|
|
system and these addresses are safely in the hands of the right users. At the
|
|
|
|
|
beginning user finds out that he/she does not remember password after that user
|
|
|
|
|
requests password reset and fill in his/her unique identifier, it might be email
|
|
|
|
|
or unique nickname. Based on matched user account system generates unique access
|
|
|
|
|
token and sends it user email address. Tokens should be time limited and usable
|
|
|
|
|
only once so they cannot be misused. User then takes token or address which was
|
|
|
|
|
provided in email and go to system in appropriate section, where new password
|
|
|
|
|
can be set. After that user can sign in with his new password. As stated this
|
|
|
|
|
solution is quite safe and user can handle it on its own administrator does not
|
|
|
|
|
have to worry about it. That is why this approach was chosen to be used in
|
|
|
|
|
ReCodEx.
|
|
|
|
|
write an email to administrator, who generated a new password and sent it back
|
|
|
|
|
to the sender. This simple solution could be also automated, but administrator
|
|
|
|
|
had quite a big control over whole process. This might come in handy if there
|
|
|
|
|
could be some additional checkups for example, but on the other hand it can be
|
|
|
|
|
quite time consuming.
|
|
|
|
|
|
|
|
|
|
Probably the best solution which is often used and is fairly secure is
|
|
|
|
|
following. Let us consider only case in which all users have to fill their
|
|
|
|
|
email addresses into the system and these addresses are safely in the hands of
|
|
|
|
|
the right users. When user finds out that he/she does not remember a password,
|
|
|
|
|
he/she requests a password reset and fill in his/her unique identifier; it might
|
|
|
|
|
be email or unique nickname. Based on matched user account the system generates
|
|
|
|
|
unique access token and sends it user via email address. This token should be
|
|
|
|
|
time limited and usable only once, so it cannot be misused. User then takes the
|
|
|
|
|
token or URL address which is provided in the email and go to the system's
|
|
|
|
|
appropriate section, where new password can be set. After that user can sign in
|
|
|
|
|
with his/her new password. As previously stated, this solution is quite safe and
|
|
|
|
|
user can handle it on its own, so administrator does not have to worry about it.
|
|
|
|
|
That is the main reason why this approach was chosen to be used in ReCodEx.
|
|
|
|
|
|
|
|
|
|
### Evaluation unit executed by ReCodEx
|
|
|
|
|
|
|
|
|
|