[radext] Security of MS-CHAP

Alan DeKok <aland@deployingradius.com> Tue, 29 August 2023 20:13 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB19C13AE49 for <radext@ietfa.amsl.com>; Tue, 29 Aug 2023 13:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jXK9oY3W4u2 for <radext@ietfa.amsl.com>; Tue, 29 Aug 2023 13:13:44 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8359C13AE47 for <radext@ietf.org>; Tue, 29 Aug 2023 13:13:43 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id E4B1810D for <radext@ietf.org>; Tue, 29 Aug 2023 20:13:40 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Message-Id: <530B7883-826D-40F0-8948-09443C12021B@deployingradius.com>
Date: Tue, 29 Aug 2023 16:13:39 -0400
To: radext@ietf.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/8gE4-bNZ2snjDqQD41Ad_DTxv_4>
Subject: [radext] Security of MS-CHAP
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2023 20:13:50 -0000

  I hadn't seen this before.  The GitHub repo has a terrible name, but I thought this would be interesting:

https://github.com/sensepost/assless-chaps

  In short, MS-CHAP uses the 16 octet NT hash to derive 3 DES keys, each needing 7 octets.  Since 16 is smaller than 21, the final DES key has 2 octets of the NT hash, and 5 octets of zero.   (RFC2759 Section 8.3)

  The result is that an attacker can recover the last 2 octets with only 2^16 DES operations.  Those octets can be used as an index into a pre-existing database which maps "NT hash -> password".

  As the database is indexed on those 2 octets, a the query returns only a small number of NT hashes, usually on the order of a a few hundred or less.  Those hashes can then be brute-forced against the MS-CHAP data.

  The result is that for most passwords in the database, the cost of inverting MS-CHAP to get the password is on the order of milliseconds, maybe tens of milliseconds.

  This makes MS-CHAP significantly easier to crack than User-Password! 

  Strong passwords still need to be brute forced, as they won't  appear in the database.  But for common passwords. the construction of MS-CHAP means that there are attacks which are 5 orders of magnitude faster than brute force.

  I think it's safe to assume that if you send MS-CHAP data in RADIUS/UDP across the Internet, your password has been compromised.

  I'll update the "deprecation" document with this analysis.  Given how the document has transformed, I think it's worth changing the name.  The focus is now on deprecating insecure uses of RADIUS (transport protocol and data being transported), and recommending ways to increase RADIUS security and privacy.

  In short: MS-CHAP MUST NOT be sent in RADIUS/UDP or RADIUS/TCP.

  Alan DeKok.