-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Juniper/NetBSD sha1crypt #1204
Comments
Wow, I would call this a really great example of a feature request description. Well done. So, I already did all the preparation... host code (including parser etc). |
Thanks! You and @jsteube were my primary target audience, so if it's a good writeup (and a successful one!), then mission accomplished. I also wanted to try to create a good example for others to use as a reference. Minor edit: I added a few more 'hashcat' NetBSD examples, to demonstrate the spread of the iteration counts. |
I can only agree, very good description. If only all requests would look like that. Please test the implementation and close the issue if fixed. |
While sha1crypt may not currently be common, I anticipate that its use will in
crease. Since the only other options on JunOS appear to be descrypt and md5cry
pt, it is currently the strongest option on that platform.
FWIW recent Junos supports more options including those found in recent
FreeBSD.
|
On Thu, 23 Mar 2017 07:34:19 -0700, Royce Williams writes:
Minor edit: I added a few more 'hashcat' NetBSD examples, to demonstrate the s
pread of the iteration counts.
Yes, the number of iterations was semi-randomized to make dictionary
attacks more expensive, goal was approximate 1s runtime.
|
Ah, indeed - I missed the mention of SHA-256 and SHA-512 from 3.13 onwards in the Juniper docs. Thanks, @sgerraty! (And good to hear from you. I'm a FreeBSD and Juniper fan - thanks for your work on both.) |
As expected, a pretty slow hash:
|
A potential new hash target.
Name: Juniper/NetBSD sha1crypt
Use: Currently used on Juniper routers and switches, and also available on NetBSD systems, and maybe other BSDs (but not modern FreeBSD or OpenBSD).
sha1crypt is not the default algorithm on Junipers, and must be enabled with this Junos OS command (and then committing the configuration):
set system login password format sha1
It is also apparently automatically enabled when using the Junos-FIPS variant of the OS (ref here).
While perhaps less common, sha1crypt is interesting for a few reasons:
Strength. sha1crypt's rounds as implemented in Junos OS are based on an upper bound provided as a parameter at creation time and used as a "hint" (see the NetBSD pwhash(1) manpage) , resulting in a significantly slower hash than md5crypt. This will make it more attractive to security-minded defenders.
Compliance pressure. The recent deprecation of md5crypt by @bsdphk will mean that organizations subject to external audit will be more likely to override the default and select this slower hash.
Attack asymmetry. @jsteube has noted that the algorithm is using HMAC, but using it incorrectly, with the potential to speed up cracking by 50% compared to the defender. This asymmetry may be worth demonstrating.
Feature parity. John the Ripper jumbo already supports it ;) (Hi, @magnumripper!)
I anticipate that the use of sha1crypt on Junipers will increase. Since the only other options supported by Junos OS
appear to bewere descrypt and md5crypt, itis currentlywas the strongest option on that platform until Junos OS 13.3, when modern FreeBSD hashes like sha256crypt and sha512crypt were added.Source code: Access to original Junos OS source code is limited, but the NetBSD implementation appears to be very similar. From its commit message:
Other source commentary is in this mailing-list post from 2004 by @sgerraty, and the replies at the bottom of this thread summary.
Source from John the Ripper jumbo is in sha1crypt_common.h, sha1crypt_common_plug.c, and opencl_sha1crypt_fmt_plug.c.
Complexity requirements: These will vary by platform, since they are customizable. There are complexity configuration options on Juniper gear, but it is not yet clear what the defaults are, though this reference may be informative, and says:
The plain string 'hashcat' does not meet the default FIPS requirements. The native Juniper examples below are complex enough to meet them. On the NetBSD side, we can presume that the NetBSD implementation is similar to other Unix-like hashes such as md5crypt on that platform, as 'hashcat' is happily accepted.
Examples:
The hashes are of the form:
The following two example hashes have been verified by a colleague as usable to directly log into a Juniper device:
The following two hashes appear in a thread about the format that includes actual Juniper employees:
On a NetBSD 6.0 amd64 system,
pwhash -S 20000 hashcat
yields hashes like these (and note that the '20000' provides the upper bound for the number of rounds, which is then randomly selected to be close to, but not exceed, that parameter):As a cross-check, JtR-jumbo successfully cracks all of the hashes listed above:
P.S. @philsmd, I'm told that I first need to convince you to write a parser for this algorithm. :)
The text was updated successfully, but these errors were encountered: