You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Stephen McCants <st...@hcs.us.com> on 2013/06/20 01:01:47 UTC

Password 'password' hard coded to fail?

Hello All,

	I'm a new user to Shiro and still very much on the learning curve. I
recently ran into a strange problem that seems to be that Shiro will not
allow a log in if the password is set to 'password'.  Is that really
hard coded somewhere inside Shiro?  While good passwords are wise, I
just spent two hours wondering why I couldn't log in when the only
problem seems to be that I choose a trivial password while I'm learning
how to use Shiro and it is only deployed on my laptop.  This 'feature'
also doesn't seem to be in the documentation and I don't understand
enough to delve into the source code and look for it.
      So, is it really hard coded to prevent log ins with the password
'password'?  If so, what other follies is Shiro secretly preventing?  Is
that really a good idea to have Shiro rejecting passwords or should that
be delegated to something that checks password strength when a password
is being setup?
      Thanks!

          Sincerely,
              Stephen McCants

-- 
Stephen McCants
Senior Software Engineer
Healthcare Control Systems
1-877-877-8795 x116


Re: Password 'password' hard coded to fail?

Posted by Jared Bunting <ja...@peachjean.com>.
At first glance, your setup looks about right.  It might be useful to just
step through the code.  I would start with a breakpoint in
the getAuthenticationInfo(AuthenticationToken token) method of
AuthenticatingRealm.

-Jared


On Thu, Jun 20, 2013 at 9:58 AM, Stephen McCants <stephen.mccants@hcs.us.com
> wrote:

>  Hello Jared and Thibault,
>
> I'm glad to hear this behavior is not in Shiro.  I currently have a my
> password stored in my database in plain text (until I get things working
> well enough that I'm willing to encrypt the password).  If I set the
> password to 'password' and try to login, it seems to fail and leaves me at
> the login.html page instead of redirecting me as it should after a
> successful login.  If I set the password to something else, then when I log
> in I'm redirected to the success page.  I've attached my shiro.ini file and
> login.html page.
>
> Any thoughts on this strange behavior?  It may not be very important, but
> it is a little concerning that I might have a bug in my setup that could
> cause later log in failures with reasonable passwords.
>
> Thanks for your help!
>
> Sincerely,
> Stephen McCants
>
> Here is my shiro.ini file:
>
> [main]
> # Take 2 on a shared cache/Single Sign On that can be used by both REST and Schedule.
> # Based on F_A_V's instructions from here:
> # http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-td5560737.html
>
> # Cache for single sign on
> ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
> #ssoCacheManager.cacheManager = com.hcs.org.ehcache.SingletonEhCacheFactory
> ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml
> securityManager.cacheManager = $ssoCacheManager
>
> # native for single sign on
> #securityManager.sessionMode = native
>
> # DAO for single sign on
> sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
> sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
> sessionManager.sessionDAO = $sessionDAO
> securityManager.sessionManager = $sessionManager
> ##securityManager.sessionManager.sessionDAO = $sessionDAO
>
> # https://cwiki.apache.org/confluence/display/SHIRO/Session+Management#SessionManagement-SessionTimeout
> # this sets up the session purge. Sessions inactive for over an hour will
> # be purged from the database. the interval is set in milliseconds.
> sessionValidationScheduler = org.apache.shiro.session.mgt.ExecutorServiceSessionValidationScheduler
> sessionValidationScheduler.interval = 60000
> sessionValidationScheduler.sessionManager = $sessionManager
> securityManager.sessionManager.sessionValidationScheduler = $sessionValidationScheduler
> securityManager.sessionManager.sessionValidationSchedulerEnabled = true
>
> # cookie for single sign on
> # this sets up the session cookie. the name is the cookie name
> # and the path is the cookie path. by setting the path to / we
> # can use it across domains. ajax will automatically pick it up
> # from the browser and send it with all calls to REST.
> # using the default session name JSESSIONID but anything can
> # be used.
> cookie = org.apache.shiro.web.servlet.SimpleCookiecookie.name = JSESSIONID
> cookie.path = /
> securityManager.sessionManager.sessionIdCookie = $cookie
>
> # authc is the form based authentication filter from shiro
> # the usernameParam and passwordParam below specify that the
> # form submitted will have will have inputs of those names
> # the login url is the login page.
> # If the login attempt fails, the resulting AuthenticationException fully
> # qualified class name will be set as a request attribute under the failureKeyAttribute key.
> # This can be used as an i18n key or lookup mechanism to explain to the user
> # why their login attempt failed (e.g. no account, incorrect password, etc).
> authc.usernameParam = j_username
> authc.passwordParam = j_password
> authc.loginUrl = /login.html
> authc.successUrl = /index.html
> authc.failureKeyAttribute = shiroLoginFailure
>
> # Logout filter configuration (b/c it sends us off the bad places)
> logout.redirectUrl = /login.html?logout=true
>
> # This is the connection information to the datbase
> # that will be used for authentication. Where
> # the user names and passwords are stored.
> # TODO move this OUT of the shiro.ini so that it isn't part of the WAR file. (WTL-141)
> ds = com.mysql.jdbc.jdbc2.optional.MysqlDataSource
> ds.serverName = localhost
> ds.user = root
> ds.password = XXXXX
> ds.databaseName = webtl
>
> # the authenticationQuery is the sql used to get the password from the db.
> jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm
> jdbcRealm.dataSource = $ds
> jdbcRealm.authenticationQuery = SELECT password FROM webtl.access_requests where email_address = ?
>
> [urls]
> # The /login.html is not restricted to authenticated users (otherwise no one could log in!), but
> # the 'authc' filter must still be specified for it so it can process that url's
> # login submissions. It is 'smart' enough to allow those requests through as specified by the
> # shiro.loginUrl above.
> # The line below says that anything under / will use the form base authentication as configured
> # above to authenticate.
> # The format is as this: URL_Ant_Path_Expression = Path_Specific_Filter_Chain
> # this means that different authentication can be used for different paths.
> #/admin.html = authc,perms
> /img/* = anon
> /lib/* = anon
> # The JavaScript files below are available to support the signup page.
> /js/util.js = anon
> /js/loader.js = anon
> /js/signup.js = anon
> # Common.js is available to support internationalization.
> /js/common.js = anon
> /bundle/* = anon
> /style/* = anon
> /signup.html = anon
> /logout = authc, logout
> /** = authc
>
>
> Here is my login.html file:
>
> <html>
> 	<head>
> 		<title>Login</title>
> 		<script src="lib/jquery-1.7.2.min.js"></script> <!-- Need JQuery to let us manipulate some text. -->
> 	</head>
> 	<body>
> 	<table>
> 		<tr>
> 	    	<td>
> 	        	<img src="img/hcslogo.png" />
> 	        </td>
> 	    	<td>
> 				<h1>OR <span class="color">Control<span class="superscript2">™</span></span></h1>
> 	        </td>
> 	    </tr>
> 	</table>
> 	<p name='logged_out'>You have been successfully logged out.</p>
> 	<form action="" id="loginForm" method="post">
> 		<p>
> 		<label for="username" id="username-label">Username</label><br/>
> 		<input id="username" type="text" name="j_username"/><br/>
>
> 		<label for="password">Password</label><br/>
> 		<input id="password" type="password" name="j_password"/><br/>
>
> 		<input type="checkbox" name="rememberMe" id="rememberMe"/>
> 		<label for="rememberMe" style="vertical-align: top">Remember Me</label><br/>
>
> 		<input type="submit" id="login" class="button" value="Login"/>
> 		<input type="reset" id="reset" class="button" value="Clear"/>
> 		</p>
> 	</form>
> 	<p>Copy Right Information Here</p>
> 	
> 	<script>
> 		<!-- This shows or hides the text stating that you've successfully logged out -->
> 		var results = new RegExp('[\\?&amp;]' + 'logout' + '=([^&amp;#]*)').exec(window.location.href);
> 		if(results != null && results[1] != null) {
>     		$("p[name=logged_out]").show();
> 		} else {
> 			$("p[name=logged_out]").hide();
> 		}
> 	</script>
> 	</body>
> </html>
>
>
> On 6/19/2013 7:31 PM, Jared Bunting wrote:
>
> I am not aware of this behavior existing in the shiro codebase.  Perhaps
> you could share what it is that you've configured and seen to lead you to
> this conclusion?
>
> -Jared
> On Jun 19, 2013 6:02 PM, "Stephen McCants" <st...@hcs.us.com>
> wrote:
>
>> Hello All,
>>
>>         I'm a new user to Shiro and still very much on the learning
>> curve. I
>> recently ran into a strange problem that seems to be that Shiro will not
>> allow a log in if the password is set to 'password'.  Is that really
>> hard coded somewhere inside Shiro?  While good passwords are wise, I
>> just spent two hours wondering why I couldn't log in when the only
>> problem seems to be that I choose a trivial password while I'm learning
>> how to use Shiro and it is only deployed on my laptop.  This 'feature'
>> also doesn't seem to be in the documentation and I don't understand
>> enough to delve into the source code and look for it.
>>      So, is it really hard coded to prevent log ins with the password
>> 'password'?  If so, what other follies is Shiro secretly preventing?  Is
>> that really a good idea to have Shiro rejecting passwords or should that
>> be delegated to something that checks password strength when a password
>> is being setup?
>>      Thanks!
>>
>>          Sincerely,
>>              Stephen McCants
>>
>> --
>> Stephen McCants
>> Senior Software Engineer
>> Healthcare Control Systems
>> 1-877-877-8795 x116
>>
>>
>
> --
> Stephen McCants
> Senior Software Engineer
> Healthcare Control Systems1-877-877-8795 x116
>
>

Re: Password 'password' hard coded to fail?

Posted by Stephen McCants <st...@hcs.us.com>.
Hello Jared and Thibault,

I'm glad to hear this behavior is not in Shiro.  I currently have a my 
password stored in my database in plain text (until I get things working 
well enough that I'm willing to encrypt the password).  If I set the 
password to 'password' and try to login, it seems to fail and leaves me 
at the login.html page instead of redirecting me as it should after a 
successful login.  If I set the password to something else, then when I 
log in I'm redirected to the success page.  I've attached my shiro.ini 
file and login.html page.

Any thoughts on this strange behavior?  It may not be very important, 
but it is a little concerning that I might have a bug in my setup that 
could cause later log in failures with reasonable passwords.

Thanks for your help!

Sincerely,
Stephen McCants

Here is my shiro.ini file:

[main]
# Take 2 on a shared cache/Single Sign On that can be used by both REST and Schedule.
# Based on F_A_V's instructions from here:
# http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-td5560737.html

# Cache for single sign on
ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
#ssoCacheManager.cacheManager = com.hcs.org.ehcache.SingletonEhCacheFactory
ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml
securityManager.cacheManager = $ssoCacheManager

# native for single sign on
#securityManager.sessionMode = native

# DAO for single sign on
sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
sessionManager.sessionDAO = $sessionDAO
securityManager.sessionManager = $sessionManager
##securityManager.sessionManager.sessionDAO = $sessionDAO

# https://cwiki.apache.org/confluence/display/SHIRO/Session+Management#SessionManagement-SessionTimeout
# this sets up the session purge. Sessions inactive for over an hour will
# be purged from the database. the interval is set in milliseconds.
sessionValidationScheduler = org.apache.shiro.session.mgt.ExecutorServiceSessionValidationScheduler
sessionValidationScheduler.interval = 60000
sessionValidationScheduler.sessionManager = $sessionManager
securityManager.sessionManager.sessionValidationScheduler = $sessionValidationScheduler
securityManager.sessionManager.sessionValidationSchedulerEnabled = true

# cookie for single sign on
# this sets up the session cookie. the name is the cookie name
# and the path is the cookie path. by setting the path to / we
# can use it across domains. ajax will automatically pick it up
# from the browser and send it with all calls to REST.
# using the default session name JSESSIONID but anything can
# be used.
cookie = org.apache.shiro.web.servlet.SimpleCookie
cookie.name = JSESSIONID
cookie.path = /
securityManager.sessionManager.sessionIdCookie = $cookie

# authc is the form based authentication filter from shiro
# the usernameParam and passwordParam below specify that the
# form submitted will have will have inputs of those names
# the login url is the login page.
# If the login attempt fails, the resulting AuthenticationException fully
# qualified class name will be set as a request attribute under the failureKeyAttribute key.
# This can be used as an i18n key or lookup mechanism to explain to the user
# why their login attempt failed (e.g. no account, incorrect password, etc).
authc.usernameParam = j_username
authc.passwordParam = j_password
authc.loginUrl = /login.html
authc.successUrl = /index.html
authc.failureKeyAttribute = shiroLoginFailure

# Logout filter configuration (b/c it sends us off the bad places)
logout.redirectUrl = /login.html?logout=true

# This is the connection information to the datbase
# that will be used for authentication. Where
# the user names and passwords are stored.
# TODO move this OUT of the shiro.ini so that it isn't part of the WAR file. (WTL-141)
ds = com.mysql.jdbc.jdbc2.optional.MysqlDataSource
ds.serverName = localhost
ds.user = root
ds.password = XXXXX
ds.databaseName = webtl

# the authenticationQuery is the sql used to get the password from the db.
jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm
jdbcRealm.dataSource = $ds
jdbcRealm.authenticationQuery = SELECT password FROM webtl.access_requests where email_address = ?

[urls]
# The /login.html is not restricted to authenticated users (otherwise no one could log in!), but
# the 'authc' filter must still be specified for it so it can process that url's
# login submissions. It is 'smart' enough to allow those requests through as specified by the
# shiro.loginUrl above.
# The line below says that anything under / will use the form base authentication as configured
# above to authenticate.
# The format is as this: URL_Ant_Path_Expression = Path_Specific_Filter_Chain
# this means that different authentication can be used for different paths.
#/admin.html = authc,perms
/img/* = anon
/lib/* = anon
# The JavaScript files below are available to support the signup page.
/js/util.js = anon
/js/loader.js = anon
/js/signup.js = anon
# Common.js is available to support internationalization.
/js/common.js = anon
/bundle/* = anon
/style/* = anon
/signup.html = anon
/logout = authc, logout
/** = authc

Here is my login.html file:

<html>
	<head>
		<title>Login</title>
		<script src="lib/jquery-1.7.2.min.js"></script> <!-- Need JQuery to let us manipulate some text. -->
	</head>
	<body>
	<table>
		<tr>
	    	<td>
	        	<img src="img/hcslogo.png" />
	        </td>
	    	<td>
				<h1>OR <span class="color">Control<span class="superscript2">™</span></span></h1>
	        </td>
	    </tr>
	</table>
	<p name='logged_out'>You have been successfully logged out.</p>
	<form action="" id="loginForm" method="post">
		<p>
		<label for="username" id="username-label">Username</label><br/>
		<input id="username" type="text" name="j_username"/><br/>

		<label for="password">Password</label><br/>
		<input id="password" type="password" name="j_password"/><br/>

		<input type="checkbox" name="rememberMe" id="rememberMe"/>
		<label for="rememberMe" style="vertical-align: top">Remember Me</label><br/>

		<input type="submit" id="login" class="button" value="Login"/>
		<input type="reset" id="reset" class="button" value="Clear"/>
		</p>
	</form>
	<p>Copy Right Information Here</p>
	
	<script>
		<!-- This shows or hides the text stating that you've successfully logged out -->
		var results = new RegExp('[\\?&amp;]' + 'logout' + '=([^&amp;#]*)').exec(window.location.href);
		if(results != null && results[1] != null) {
     		$("p[name=logged_out]").show();
		} else {
			$("p[name=logged_out]").hide();
		}
	</script>
	</body>
</html>


On 6/19/2013 7:31 PM, Jared Bunting wrote:
>
> I am not aware of this behavior existing in the shiro codebase.  
> Perhaps you could share what it is that you've configured and seen to 
> lead you to this conclusion?
>
> -Jared
>
> On Jun 19, 2013 6:02 PM, "Stephen McCants" <stephen.mccants@hcs.us.com 
> <ma...@hcs.us.com>> wrote:
>
>     Hello All,
>
>             I'm a new user to Shiro and still very much on the
>     learning curve. I
>     recently ran into a strange problem that seems to be that Shiro
>     will not
>     allow a log in if the password is set to 'password'.  Is that really
>     hard coded somewhere inside Shiro?  While good passwords are wise, I
>     just spent two hours wondering why I couldn't log in when the only
>     problem seems to be that I choose a trivial password while I'm
>     learning
>     how to use Shiro and it is only deployed on my laptop.  This 'feature'
>     also doesn't seem to be in the documentation and I don't understand
>     enough to delve into the source code and look for it.
>          So, is it really hard coded to prevent log ins with the password
>     'password'?  If so, what other follies is Shiro secretly
>     preventing?  Is
>     that really a good idea to have Shiro rejecting passwords or
>     should that
>     be delegated to something that checks password strength when a
>     password
>     is being setup?
>          Thanks!
>
>              Sincerely,
>                  Stephen McCants
>
>     -- 
>     Stephen McCants
>     Senior Software Engineer
>     Healthcare Control Systems
>     1-877-877-8795 x116 <tel:1-877-877-8795%20x116>
>


-- 
Stephen McCants
Senior Software Engineer
Healthcare Control Systems
1-877-877-8795 x116


Re: Password 'password' hard coded to fail?

Posted by Thibault TIGEON <th...@gmail.com>.
Hi Stephen,

I agree with Jared, it is not in the shiro codebase.

Rgds ,

Thibault


2013/6/20 Jared Bunting <ja...@peachjean.com>

> I am not aware of this behavior existing in the shiro codebase.  Perhaps
> you could share what it is that you've configured and seen to lead you to
> this conclusion?
>
> -Jared
> On Jun 19, 2013 6:02 PM, "Stephen McCants" <st...@hcs.us.com>
> wrote:
>
>> Hello All,
>>
>>         I'm a new user to Shiro and still very much on the learning
>> curve. I
>> recently ran into a strange problem that seems to be that Shiro will not
>> allow a log in if the password is set to 'password'.  Is that really
>> hard coded somewhere inside Shiro?  While good passwords are wise, I
>> just spent two hours wondering why I couldn't log in when the only
>> problem seems to be that I choose a trivial password while I'm learning
>> how to use Shiro and it is only deployed on my laptop.  This 'feature'
>> also doesn't seem to be in the documentation and I don't understand
>> enough to delve into the source code and look for it.
>>      So, is it really hard coded to prevent log ins with the password
>> 'password'?  If so, what other follies is Shiro secretly preventing?  Is
>> that really a good idea to have Shiro rejecting passwords or should that
>> be delegated to something that checks password strength when a password
>> is being setup?
>>      Thanks!
>>
>>          Sincerely,
>>              Stephen McCants
>>
>> --
>> Stephen McCants
>> Senior Software Engineer
>> Healthcare Control Systems
>> 1-877-877-8795 x116
>>
>>

Re: Password 'password' hard coded to fail?

Posted by Jared Bunting <ja...@peachjean.com>.
I am not aware of this behavior existing in the shiro codebase.  Perhaps
you could share what it is that you've configured and seen to lead you to
this conclusion?

-Jared
On Jun 19, 2013 6:02 PM, "Stephen McCants" <st...@hcs.us.com>
wrote:

> Hello All,
>
>         I'm a new user to Shiro and still very much on the learning curve.
> I
> recently ran into a strange problem that seems to be that Shiro will not
> allow a log in if the password is set to 'password'.  Is that really
> hard coded somewhere inside Shiro?  While good passwords are wise, I
> just spent two hours wondering why I couldn't log in when the only
> problem seems to be that I choose a trivial password while I'm learning
> how to use Shiro and it is only deployed on my laptop.  This 'feature'
> also doesn't seem to be in the documentation and I don't understand
> enough to delve into the source code and look for it.
>      So, is it really hard coded to prevent log ins with the password
> 'password'?  If so, what other follies is Shiro secretly preventing?  Is
> that really a good idea to have Shiro rejecting passwords or should that
> be delegated to something that checks password strength when a password
> is being setup?
>      Thanks!
>
>          Sincerely,
>              Stephen McCants
>
> --
> Stephen McCants
> Senior Software Engineer
> Healthcare Control Systems
> 1-877-877-8795 x116
>
>