[rancid] Going beyond community <removed>?

[K K]

I have a need to not just remove passwords/keys from saved configs,
but also to know when they change.

Specifically, I was thinking of replacing the actual password or community
with a high-collision hash of the password, followed by the number of
"bits of entropy", similar to the calculator found here:
http://www.certainkey.com/demos/password/

Would there be interest in a patch to add this feature to RANCID?


For example if I have a router with this SNMP community:
snmp-server community AndBobsYourUncle RW

Right now RANCID just shows <removed> for the community string,
instead I would like to have it show something like:

snmp-server community <HASH:ac499d,4> RW

In this case, '4' is a generous estimate of the bits of entropy.
With a correctly implemented hash, this isn't sufficient information
to crack the community string from looking at the saved config,
but does give an auditor confidence that communities and keys are
being chosen correctly, and changed on schedule.


Kevin

(P.S. Yes, the "bits of entropy" would only be useful for cleartext keys,
not for Cisco "Type 5", ASA radius keys or other encrypted values.)

[john heasley]

Post by K K
I have a need to not just remove passwords/keys from saved configs,
but also to know when they change.
Specifically, I was thinking of replacing the actual password or community
with a high-collision hash of the password, followed by the number of
http://www.certainkey.com/demos/password/
Would there be interest in a patch to add this feature to RANCID?
snmp-server community AndBobsYourUncle RW
Right now RANCID just shows <removed> for the community string,
snmp-server community <HASH:ac499d,4> RW

just create your own md5 for whatever you're removing. wouldnt seem
necessary to go though anything more extravagant.

Post by K K
In this case, '4' is a generous estimate of the bits of entropy.
With a correctly implemented hash, this isn't sufficient information
to crack the community string from looking at the saved config,
but does give an auditor confidence that communities and keys are
being chosen correctly, and changed on schedule.
Kevin
(P.S. Yes, the "bits of entropy" would only be useful for cleartext keys,
not for Cisco "Type 5", ASA radius keys or other encrypted values.)
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

[K K]

Post by K K
I have a need to not just remove passwords/keys from saved configs,
but also to know when they change.

. . .

Post by K K

Post by K K
snmp-server community <HASH:ac499d,4> RW

just create your own md5 for whatever you're removing. wouldnt seem
necessary to go though anything more extravagant.

Using the full MD5 hash makes the attacker's job easier, as they
can use rainbow tables or dictionary crack tool, and the defender's
more difficult -- weak or strong, all hashed values look alike.

Truncating the MD5 hash to a few bytes addresses that first issue,
and RANCID would now detect when the original string changes,
with equivalent security as the original <removed> behavior.


Is there a better way to address my secondary requirement for auditors,
enabling them to validate not only that the shared secret is changed
regularly, but also that "strong" communities are used?

Preferably building on tried-and-true crypto rather than roll-my-own,
but without saving huge blobs of PGP-encrypted stuff.


Kevin

[Austin Schutz]

Post by K K

Post by K K
I have a need to not just remove passwords/keys from saved configs,
but also to know when they change.

. . .

Post by K K

Post by K K
snmp-server community <HASH:ac499d,4> RW

just create your own md5 for whatever you're removing. wouldnt seem
necessary to go though anything more extravagant.

Using the full MD5 hash makes the attacker's job easier, as they
can use rainbow tables or dictionary crack tool, and the defender's
more difficult -- weak or strong, all hashed values look alike.
Truncating the MD5 hash to a few bytes addresses that first issue,
and RANCID would now detect when the original string changes,
with equivalent security as the original <removed> behavior.
Is there a better way to address my secondary requirement for auditors,
enabling them to validate not only that the shared secret is changed
regularly, but also that "strong" communities are used?

This seems pretty smart to me, and a useful feature. My only comment
would be that this is really more like using a CRC checksum- it's not really a
matter of cryptography. You could use Digest::MD5 if you wanted to go the
MD5 route, or maybe Digest::CRC if not.

Austin

[K K]

Post by Austin Schutz
This seems pretty smart to me, and a useful feature. My only comment
would be that this is really more like using a CRC checksum- it's not really a
matter of cryptography. You could use Digest::MD5 if you wanted to go the
MD5 route, or maybe Digest::CRC if not.

Good point. I'm using String::CRC32 and Statistics::Shannon,
looks like these together do exactly what I was looking for.

I've made the change to "rancid" for SNMP community strings,
patch included below.

Kevin


begin 644 rancid.patch.gz
M'XL(")3>M4@``W)A;F-I9"YP871C:`"=4UUOVC`4?89?<6ME$*\)D(\"A1(Q
MH4J\L%9DVA,:RH(96<&)8M,53?SW73LI!3%4;7EPG.M[SKD^]\;O1'[7NFE5
M`]@*!J',$_ZCUQM-1Y[;/P0CF0B9Q*+7"U<1YRE71]5;/[KM6DZKBQ]B^QW*
MLW$D5O`;8YN=:***@6YTS2@3F<TWX96V$"'9#QIW#<(YI)Q6&XB&0T$-DZD6:S
M:;U""Q0869K!X&^UV`%GOTR-IB4;XK8Y-\E=H0$-B//8<P_E8(!8*BPRO*]<
MFN2#TW"7Q%(J=I#P!7O120$!S;DO>*M.Q_%BI^-VJG=0299@-K\)OLELP?)G
MEL,J%1+,V>)ZUCA9*#0I6F+;-I+\$\Z<A==***@U&ZC=)>2TE7E(_KA#.*GI`S
M*B/)T-A2[OU<((W:4?-,P\5+*RG4\WVM5]$,BN"JV"GW?J8)-^M0MP"MSMDF
M?6:+@%AO\:%,***@7E-*W:MYC.JU$$]`+E%CB;>1T;GS+Z;35"%?86EQT-U1V
M-CY"G&XV6Y[(7>***@J'$0_X*`)CF:PER^<J5\B\/#VN_=Q'!PP7G833"WAJ
***@R_7^`?\S1F0HQQA--\9Y+P\^0QO)]^O9^.'\(O.)-))M)<XL9PU*+D9IS0
M$L[9B^Q7BOU>***@N]BG]J>,J%HUF65T<-***@KQ/;/<J,\?E"FL_],^H$PJU
<&FBMHQD"_=\.S@<E^$]%S7>J]@=PFT>"***@0`````
`
end