bind and bind_as methods return results if a empty password is submitted #5

Open
halostatue opened this Issue Jul 12, 2011 · 9 comments

Comments

Projects
None yet
8 participants
@halostatue

Originally submitted as issue 8591 on RubyForge on 2007-02-13.

bind and bind_as return results if a empty password is submitted. If a incorrect password is given it fails. However
to my mind, if you don't provide a password the bind should fail. I think this is a bug. The code below follows the
example code.

Here is the code that I've run to test. As you can see by the result, this ends up returning the same results regardless
if you enter a password or if you enter the correct pass. You only get a failure when you enter the incorrect password.

#################################

require 'rubygems'
require 'net/ldap'
require 'pp'

ldap = Net::LDAP.new
ldap.host = "192.168.1.16"
ldap.port = 389

####################
#  NO PASSWORD
####################

username,password = "pnovess", ""

result = ldap.bind_as(
 :base => "dc=net",
 :filter => "(cn=#{username})",
 :password => password
)

if result
  pp result
else
  puts "Authentication FAILED."
  pp result
end


####################
#  CORRECT PASSWORD
####################

username,password = "pnovess", "correct"

result = ldap.bind_as(
 :base => "dc=net",
 :filter => "(cn=#{username})",
 :password => password
)

if result
  pp result
else
  puts "Authentication FAILED."
  pp result
end

####################
#  INCORRECT PASSWORD
####################

username,password = "pnovess", "incorrect"

result = ldap.bind_as(
 :base => "dc=net",
 :filter => "(cn=#{username})",
 :password => password
)

if result
  pp result
else
  puts "Authentication FAILED."
  pp result
end
@halostatue

This comment has been minimized.

Show comment
Hide comment
@halostatue

halostatue Jul 12, 2011

Comment by Rubyforge user bidon on 2007-08-31:

That's not the Net::LDAP fault. Any LDAP server that allow anonymous
access allow binds with an empty password. So either you have
to disallow anonymous access on the LDAP server side or you have
to generate a random password to be used instead of the empty
one.

Comment by Rubyforge user bidon on 2007-08-31:

That's not the Net::LDAP fault. Any LDAP server that allow anonymous
access allow binds with an empty password. So either you have
to disallow anonymous access on the LDAP server side or you have
to generate a random password to be used instead of the empty
one.

@jessehub

This comment has been minimized.

Show comment
Hide comment
@jessehub

jessehub Mar 8, 2012

Contributor

I agree with bidon. LDAP servers will allow a bind with no password if so configured. It is normal to allow anonymous binding.

Contributor

jessehub commented Mar 8, 2012

I agree with bidon. LDAP servers will allow a bind with no password if so configured. It is normal to allow anonymous binding.

@jawheeler

This comment has been minimized.

Show comment
Hide comment
@jawheeler

jawheeler Apr 11, 2013

At the very least, please document this behavior in the bind and bind_as method documentation.

At the very least, please document this behavior in the bind and bind_as method documentation.

@Ajedi32

This comment has been minimized.

Show comment
Hide comment
@Ajedi32

Ajedi32 Jun 11, 2014

Note that this also applies for an empty username (dn).

Ajedi32 commented Jun 11, 2014

Note that this also applies for an empty username (dn).

@mtodd

This comment has been minimized.

Show comment
Hide comment
@mtodd

mtodd Oct 3, 2014

Member

From the spec, as @jzinn points out:

Clients SHOULD be implemented to require
user selection of the Unauthenticated Authentication Mechanism by
means other than user input of an empty password. Clients SHOULD
disallow an empty password input to a Name/Password Authentication
user interface.

Perhaps we should explicitly require a password or introduce a separate method for Unauthenticated authentication/bind operations (false password, perhaps).

Member

mtodd commented Oct 3, 2014

From the spec, as @jzinn points out:

Clients SHOULD be implemented to require
user selection of the Unauthenticated Authentication Mechanism by
means other than user input of an empty password. Clients SHOULD
disallow an empty password input to a Name/Password Authentication
user interface.

Perhaps we should explicitly require a password or introduce a separate method for Unauthenticated authentication/bind operations (false password, perhaps).

@schaary

This comment has been minimized.

Show comment
Hide comment
@schaary

schaary Oct 5, 2014

Member

Separate methods sounds good. This we match up (http://www.openldap.org/doc/admin24/security.html) 14.3 better too. This would be the final step to version 1.0 according to semver ;)

Member

schaary commented Oct 5, 2014

Separate methods sounds good. This we match up (http://www.openldap.org/doc/admin24/security.html) 14.3 better too. This would be the final step to version 1.0 according to semver ;)

@morenocarullo

This comment has been minimized.

Show comment
Hide comment
@DuBistKomisch

This comment has been minimized.

Show comment
Hide comment
@DuBistKomisch

DuBistKomisch Aug 19, 2016

I agree that the documentation definitely needs to at least mention this:

#bind_as returns false on failure. On success, it returns a result set, just as #search does. This result set is an Array of objects of type Net::LDAP::Entry. It contains the directory attributes corresponding to the user. (Just test whether the return value is logically true, if you don't need this additional information.)

It makes it sound like it only returns the user if you authenticated as that user. Just been burned by this. I assume the workaround is to do something like if result && !password.strip.blank?.

I agree that the documentation definitely needs to at least mention this:

#bind_as returns false on failure. On success, it returns a result set, just as #search does. This result set is an Array of objects of type Net::LDAP::Entry. It contains the directory attributes corresponding to the user. (Just test whether the return value is logically true, if you don't need this additional information.)

It makes it sound like it only returns the user if you authenticated as that user. Just been burned by this. I assume the workaround is to do something like if result && !password.strip.blank?.

@Ajedi32

This comment has been minimized.

Show comment
Hide comment
@Ajedi32

Ajedi32 Aug 19, 2016

My solution was to just check whether the username or password are blank before even sending the authentication request. If either are blank, then I just immediately fail the login attempt.

Ajedi32 commented Aug 19, 2016

My solution was to just check whether the username or password are blank before even sending the authentication request. If either are blank, then I just immediately fail the login attempt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment