Issue #14915 has been updated by jeremyevans0 (Jeremy Evans).


normalperson (Eric Wong) wrote:
> merch-redmine / jeremyevans.net wrote:
>  > Personally, I think it's best to punt and require the user
>  > provide implementations for creating a password hash and
>  > checking the password hash via two callable options (e.g.
>  > :create_password_hash and :check_password_hash).  That way the
>  > user can determine which password hash format they want to
>  > use, and it doesn't tie Webrick to one particular hash
>  > implementation.  If that is considered acceptable I can work
>  > on a patch for Webrick that keeps the current default behavior
>  > with a deprecation warning if the callable options are not
>  > provided.
>  
>  Is the worth the effort for you or anybody to work on
>  such an option (which still requires user education) vs
>  telling them to use Htdigest, which already exists?

I think that a single iteration of MD5 is not a significant security improvement on DES:


```
    class DigestAuth
      def self.make_passwd(realm, user, pass)
        pass ||= ""
        Digest::MD5::hexdigest([user, realm, pass].join(":"))
      end
    end
```

When using HTTP, digest auth is better than basic auth if your threat model includes connection sniffing (passive or active MITM).  When using HTTPS with trusted certificates (define trusted however you like), I'd much prefer basic auth with a strong hash function than digest auth.

----------------------------------------
Feature #14915: Deprecate String#crypt, move implementation to string/crypt
https://bugs.ruby-lang.org/issues/14915#change-73054

* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
This method is system and implementation dependent, and the
portable usage mentioned in the documentation is not truly
portable (doesn't work on OpenBSD) and insecure as it uses DES.
For systems that lack a crypt(3) implementation, Ruby will
happily substitute a version that only supports DES.  It's 2018,
using DES should be avoided if at all possible.

The only internal usage of String#crypt in Ruby is in Webrick,
where it uses DES for basic authentication with an htpasswd file.
That could and should be changed to use a more secure hash by
default (bcrypt since that's the most secure htpasswd format),
or at least allow the user to customize Webrick's authentication.
I expect there are few if any users actively using Webrick's
htpasswd support.

This moves the String#crypt implementation to the string/crypt
extension, but leaves the String#crypt core method.  The core
method prints a deprecation warning, then loads the string/crypt
extension. The string/crypt extension undefines the String#crypt
core method, then defines the previous implementation.

Because extensions use extconf.rb instead of configure for their
configuration, this ports the related configure.ac code to
extconf.rb.  I'm not sure that is done correctly and works on
all platforms, it will need testing.

For systems that lack a crypt(3) implementation, this modifies the
fallback code to only define crypt_r, since that is the only
function that String#crypt will call in that case.

While the patch just deprecates String#crypt, I think
we should plan to remove support from ruby:

2.6: core method deprecated
2.7: core method removed, string/crypt extension ships with ruby
2.8: string/crypt extension moves to external gem, not shipped

---Files--------------------------------
0001-Deprecate-String-crypt-move-implementation-to-string.patch (20.5 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>