Issue #298 has been updated by Clément Oudot. Status changed from New to Assigned Assigned to set to Clément Oudot Target version set to self-service-password-0.5
Hello Matthias, thanks for using SSP! For me there is no security issue, because we use the PHP session mechanism after HTTP headers are sent, so the session id is never sent to the client. You can check this by reading the cookies in your browser, or if you set the debug mode, you will see those messages: <pre> Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /usr/local/self-service-password/index.php:64) in /usr/local/self-service-password/pages/sendtoken.php on line 112 </pre> But your solution seems ok too, we can maybe propose each of them in the software. I like the idea to use PHP sessions mechanism, because you can then use different session backend, just by configuring PHP (it will be independent from SSP). The token lifetime issue is already opened here: #290. And I would like to have a one-time token (see #289), which is not possible with your code. ---------------------------------------- Bug #298: security issue in email password reset http://tools.lsc-project.org/issues/298 Author: Matthias Ganzinger Status: Assigned Priority: High Assigned to: Clément Oudot Category: Self Service Password Target version: self-service-password-0.5 Anybody, who knows the username and email address of another user can reset that persons password *without having access to the corresponding email account.* The reason for this is the us of the php session id as the email token. The session id is regularly sent to the requester's web browser as a cookie. However, the requestor does not necessarily have to be the owner of the account to be reset. The requester can easily read the session id from his browsers cookie store and compose a valid reset url without having access to the email sent to the account owner. To cope with this problem, I propose the following: * Do no longer use the php session id as the token * instead, use an ancrypted token. The encryption key must only be stored on the server. The token will not be sent to the webbrowser. * The token might contain the login name and a timestamp. This has the additional benefit of a token lifetime that is independent of the php session life time I did a proof of concept implementation of my suggestion: In file config.inc.php I added two parameters: <pre> # secret to encrypt email token $keyphrase = "secret"; #lifetime (in seconds) of token for email password reset $token_lifetime = 60*60 </pre> In file functions.inc.php I added two functions for encrypting (AES256) / decrypting and base64 encoding / deconding the token: <pre> function enctoken($token) function dectoken($token) </pre> In File sendtoken.php the token is generated in section "Send token by mail": <pre> # create the token $token = time() .";" . $login; $enctoken = enctoken($token); # Build reset by token URL $method = "http"; if ( $_SERVER['HTTPS'] ) { $method .= "s"; } $server_name = $_SERVER['SERVER_NAME']; $script_name = $_SERVER['SCRIPT_NAME']; $reset_url = $method."://".$server_name.$script_name."?action=resetbytoken&token=".$enctoken; </pre> Finally, in file resetbytoken.php the token is validated in section "Get token": <pre> $dectoken = dectoken($_REQUEST["token"]); $tokentime = strstr($dectoken, ';', true); $login = substr($dectoken, strpos($dectoken, ';')+1); </pre> and the token lifetime is checked: <pre> if ( time() - $tokentime > $token_lifetime ) { $result = "tokennotvalid"; error_log("Token lifetime expired"); } </pre> Thank you for your nice library! I hope my suggestions are helpful. Kind regards, Matthias -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://tools.lsc-project.org/my/account
_______________________________________________ ltb-dev mailing list [email protected] http://lists.ltb-project.org/listinfo/ltb-dev
