In this question:
Can someone explain how BCrypt verifies a hash?
Ian Boyd writes at the end of his answer:
Armed with this knowledge, you can now verify a password correctbatteryhorsestapler against the saved hash:
$2a$12$mACnM5lzNigHMaf7O1py1OLCBgGL4tYUF0N/4rS9CwDsI7ytwL4D6
I am using the following Perl program to attempt to verify this hash:
use Crypt::Eksblowfish::Bcrypt qw(bcrypt);
my $password = "correctbatteryhorsestapler";
my $hash = '$2a$12$mACnM5lzNigHMaf7O1py1OLCBgGL4tYUF0N/4rS9CwDsI7ytwL4D6';
print "Verifying password $password<br>with hash $hash<BR><BR>";
my $new_hash = bcrypt($password,$hash);
print "<pre>Original hash: " . $hash . "<br>" . "New hash: " . $new_hash . "</pre><br>";
if ($hash ne $new_hash) {
print "No match.";
}
The output of my program is as follows:
Verifying password correctbatteryhorsestapler
with hash $2a$12$mACnM5lzNigHMaf7O1py1OLCBgGL4tYUF0N/4rS9CwDsI7ytwL4D6
Original hash: $2a$12$mACnM5lzNigHMaf7O1py1OLCBgGL4tYUF0N/4rS9CwDsI7ytwL4D6
New hash: $2a$12$mACnM5lzNigHMaf7O1py1O3vlf6.BA8k8x3IoJ.Tq3IB/2e7g61Km
No match.
I wonder if, based on the information above, anyone can tell me what I am doing wrong with my Perl script (why it doesn't correctly validate the password)? If I use the hash my system generates, I do get a match:
Verifying password correctbatteryhorsestapler
with hash $2a$12$mACnM5lzNigHMaf7O1py1O3vlf6.BA8k8x3IoJ.Tq3IB/2e7g61Km
Original hash: $2a$12$mACnM5lzNigHMaf7O1py1O3vlf6.BA8k8x3IoJ.Tq3IB/2e7g61Km
New hash: $2a$12$mACnM5lzNigHMaf7O1py1O3vlf6.BA8k8x3IoJ.Tq3IB/2e7g61Km
I get the same result on two different systems (one CentOS running eksblowfish 0.009 and the other Win7 64-bit running eksblowfish 0.007, both running Perl 5.8.8).
I learn by doing, so I am hoping to understand why this isn't working for me.
The answer is that it's my fault. i gave you the wrong hash in the question for correctbatteryhorsestapler.
i picked a real hash; but not wanting to give away the password i changed it to a reference to XKCD.
i should have taken the extra moments to generate an actual hash for correctbatteryhorsestapler:
$2a$12$mACnM5lzNigHMaf7O1py1O3vlf6.BA8k8x3IoJ.Tq3IB/2e7g61Km
My fault for the confusion. In the original question i meant it as now you are ready to go out into the world, it wasn't meant to be an actual test vector.
You might want to look at some actual known test vectors:
('', '$2a$06$DCq7YPn5Rq63x1Lad4cll.', '$2a$06$DCq7YPn5Rq63x1Lad4cll.TV4S6ytwfsfvkgY8jIucDrjc8deX1s.'),
('', '$2a$08$HqWuK6/Ng6sg9gQzbLrgb.', '$2a$08$HqWuK6/Ng6sg9gQzbLrgb.Tl.ZHfXLhvt/SgVyWhQqgqcZ7ZuUtye'),
('', '$2a$10$k1wbIrmNyFAPwPVPSVa/ze', '$2a$10$k1wbIrmNyFAPwPVPSVa/zecw2BCEnBwVS2GbrmgzxFUOqW9dk4TCW'),
('', '$2a$12$k42ZFHFWqBp3vWli.nIn8u', '$2a$12$k42ZFHFWqBp3vWli.nIn8uYyIkbvYRvodzbfbK18SSsY.CsIQPlxO'),
('a', '$2a$06$m0CrhHm10qJ3lXRY.5zDGO', '$2a$06$m0CrhHm10qJ3lXRY.5zDGO3rS2KdeeWLuGmsfGlMfOxih58VYVfxe'),
('a', '$2a$08$cfcvVd2aQ8CMvoMpP2EBfe', '$2a$08$cfcvVd2aQ8CMvoMpP2EBfeodLEkkFJ9umNEfPD18.hUF62qqlC/V.'),
('a', '$2a$10$k87L/MF28Q673VKh8/cPi.', '$2a$10$k87L/MF28Q673VKh8/cPi.SUl7MU/rWuSiIDDFayrKk/1tBsSQu4u'),
('a', '$2a$12$8NJH3LsPrANStV6XtBakCe', '$2a$12$8NJH3LsPrANStV6XtBakCez0cKHXVxmvxIlcz785vxAIZrihHZpeS'),
('abc', '$2a$06$If6bvum7DFjUnE9p2uDeDu', '$2a$06$If6bvum7DFjUnE9p2uDeDu0YHzrHM6tf.iqN8.yx.jNN1ILEf7h0i'),
('abc', '$2a$08$Ro0CUfOqk6cXEKf3dyaM7O', '$2a$08$Ro0CUfOqk6cXEKf3dyaM7OhSCvnwM9s4wIX9JeLapehKK5YdLxKcm'),
('abc', '$2a$10$WvvTPHKwdBJ3uk0Z37EMR.', '$2a$10$WvvTPHKwdBJ3uk0Z37EMR.hLA2W6N9AEBhEgrAOljy2Ae5MtaSIUi'),
('abc', '$2a$12$EXRkfkdmXn2gzds2SSitu.', '$2a$12$EXRkfkdmXn2gzds2SSitu.MW9.gAVqa9eLS1//RYtYCmB1eLHg.9q'),
('abcdefghijklmnopqrstuvwxyz', '$2a$06$.rCVZVOThsIa97pEDOxvGu', '$2a$06$.rCVZVOThsIa97pEDOxvGuRRgzG64bvtJ0938xuqzv18d3ZpQhstC'),
('abcdefghijklmnopqrstuvwxyz', '$2a$08$aTsUwsyowQuzRrDqFflhge', '$2a$08$aTsUwsyowQuzRrDqFflhgekJ8d9/7Z3GV3UcgvzQW3J5zMyrTvlz.'),
('abcdefghijklmnopqrstuvwxyz', '$2a$10$fVH8e28OQRj9tqiDXs1e1u', '$2a$10$fVH8e28OQRj9tqiDXs1e1uxpsjN0c7II7YPKXua2NAKYvM6iQk7dq'),
('abcdefghijklmnopqrstuvwxyz', '$2a$12$D4G5f18o7aMMfwasBL7Gpu', '$2a$12$D4G5f18o7aMMfwasBL7GpuQWuP3pkrZrOAnqP.bmezbMng.QwJ/pG'),
('~!##$%^&*() ~!##$%^&*()PNBFRD', '$2a$06$fPIsBO8qRqkjj273rfaOI.', '$2a$06$fPIsBO8qRqkjj273rfaOI.HtSV9jLDpTbZn782DC6/t7qT67P6FfO'),
('~!##$%^&*() ~!##$%^&*()PNBFRD', '$2a$08$Eq2r4G/76Wv39MzSX262hu', '$2a$08$Eq2r4G/76Wv39MzSX262huzPz612MZiYHVUJe/OcOql2jo4.9UxTW'),
('~!##$%^&*() ~!##$%^&*()PNBFRD', '$2a$10$LgfYWkbzEvQ4JakH7rOvHe', '$2a$10$LgfYWkbzEvQ4JakH7rOvHe0y8pHKF9OaFgwUZ2q7W2FFZmZzJYlfS'),
('~!##$%^&*() ~!##$%^&*()PNBFRD', '$2a$12$WApznUOJfkEGSmYRfnkrPO', '$2a$12$WApznUOJfkEGSmYRfnkrPOr466oFDCaj4b6HY3EXGvfxm43seyhgC')
There are also tests that make sure that it doesn't fail on Unicode characters. There was a bug in an implementation somewhere that crashed when given UTF-8:
Password: ππππππππ Greek Small Letter Pi (U+03C0), eight repetitions
For which an actual hash is:
$2a$10$.TtQJ4Jr6isd4Hp.mVfZeuh6Gws4rOQ/vdBczhDx.19NFK0Y84Dle
Related
I have written a test program that generates a Bcrypt hash. This hash later needs to be verified by a PHP backend.
This is my perl code:
use Digest;
#use Data::Entropy::Algorithms qw(rand_bits);
#my $bcrypt = Digest->new('Bcrypt', cost=>10, salt=>rand_bits(16*8));
my $bcrypt = Digest->new('Bcrypt', cost=>10, salt=>'1111111111111111');
my $settings = $bcrypt->settings(); # save for later checks.
my $pass_hash = $bcrypt->add('bob')->b64digest;
print $settings.$pass_hash."\n";
This prints
$2a$10$KRCvKRCvKRCvKRCvKRCvKOoFxCE1d/OZTKQqhet3bKOq6ZVIACXBU
This does not validate as a proper hash if I use an online bcrypt tool such as https://bcrypt-generator.com
Can someone point out the error? Thanks.
Figured out the problem. I have to use bcrypt_b64digest instead of b64digest. I wish the perl documentation was clearer in which one needs to be used so that other bcrypt implementations can "get it".
my $pass_hash = $bcrypt->add('bob')->bcrypt_b64digest;
From https://metacpan.org/pod/Digest::Bcrypt#bcrypt_b64digest
Same as "digest", but will return the digest base64 encoded using the
alphabet that is commonly used with bcrypt. The length of the returned
string will be 31 and will only contain characters from the ranges
'0'..'9', 'A'..'Z', 'a'..'z', '+', and '.'
The base64 encoded string returned is not padded to be a multiple of 4
bytes long. Note: This is bcrypt's own non-standard base64 alphabet,
It is not compatible with the standard MIME base64 encoding.
Can we safely use hash tables where the key value would include white spaces in between. For ex:
my $key1="Dave 2314";
my $key2="John 3212";
$newhash{$key1}= 35;
$newhash{$key2}= 46;
I used similar piece of code in one of my program. I feel like the hashing do work, but exists function don't go well=>
print "Found\n" if (exists $newhash{$searchKey})
This gives absurd results. Sometimes it works well and return correct response if the key is present and sometimes it doesn't for the very same input. Is having white spaces in the keys the reason for such absurd functioning?
What absurd results do you get? The hash doesn't care what you have in the keys. Are you sure that you have the right thing in $searchKey? If you are taking that from user input, is there an extra newline on the end?
This works as it should:
my %newhash;
my $key1="Dave 2314";
my $key2="John 3212";
$newhash{$key1} = 35;
$newhash{$key2} = 46;
print "Found\n" if exists $newhash{$key1};
But, there's another issue. You can have code in the braces for the hash element single access. When you have just a scalar variable it works. This is a syntax error because there's a bare word Dave, a space, and a literal number 1234:
print "Found\n" if exists $newhash{Dave 2314};
This is not a syntax error though, because there's a function named Dave (that just happens to return a key that exists). I'm confident this isn't your problem:
sub Dave { 'John 3212' }
print "Found\n" if exists $newhash{Dave 2314};
Written another way:
sub Dave { 'John 3212' }
print "Found\n" if exists $newhash{ Dave(2314) };
And yet another way:
print "Found\n" if exists $newhash{ join ' ', qw(John 3212 ) };
You should have quoted that key if it was literal:
print "Found\n" if exists $newhash{'Dave 2314'};
You can have unquoted strings if they don't look like code. This looks like 'Dave':
print "Found\n" if exists $newhash{Dave};
But what about this? That dot is actually the string concatenation operator and it thinks Dave is a bare word. It you haven't defined a subroutine, this is a syntax error:
print "Found\n" if exists $newhash{Dave.John};
This works though. The thing before the dot is a subroutine call but the thing after is a string:
sub Dave { 'John 3212' }
print "Found\n" if exists $newhash{Dave.John};
So there are some weird edge cases. But I typically don't have this problem because I always quote literal keys.
Thanks to all for investing your time.
The issue was in my code itself. The entire logic was based on a flag variable which i didnt reset properly as and when required.
So to answer my own question, whitespaces in between the key string should not be a problem.
snmpenum.pl is introduced in many materials about penetration testing, although it's already a very ancient program.
I downloaded it from here.
And this is the problem I encountered.
$ perl snmpenum.pl 192.168.1.36 public linux.txt # official usage
----------------------------------------
SYSTEM INFO
----------------------------------------
" is expected in dotted decimal notation..1.2.1.1.1
I have no knowledge about Perl. Can anyone tell me whether there's a problem in linux.txt or where the real problem lies? Thanks.
I've been doing a little debugging of the snmpenum.pl script and the NEt::SNMP is doing fine, the problem is the way the script splits the values when reading the lines from the OID values file (linux.txt, windows.txt, cisco.txt).
SOLUTION:
If you add a \t at the end of each line in the windows.txt/linux.txt/cisco.txt file the script is working again!
I've found that if you replace the read OID value by a hardcoded string such as "1.3.6.1.2.1.1.5" (or whatever value you want) the Net::SNMP->session.get_bulk_request() query works.
my $result = $session-get_bulk_request(){
-callback => [\&table_cb, {}],
-maxrepetitions => 10,
-varbindlist => [$v]
};
With the hardcoded strings:
my $result = $session-get_bulk_request(){
-callback => [\&table_cb, {}],
-maxrepetitions => 10,
-varbindlist => ["1.3.6.1.2.1.1.5"]
};
So I went to see how the var $v is created, and it is read from the file and the code does a split based on the \t char, which is not present at the end of the line. So I assumed the last value will perhaps contain any bogus char ascii code from the end of the line (line feed or carriage return?):
while (<CONFIG>){
chomp $_;
my #system= split /\t+/,$_;
Finally I added a \t (Tab) at the end of the line on the windows.txt, linux,txt and cisco.txt files that are distributed with snmpenum.pl and all worked fine!. For ex with this:
for filename in $(ls *.txt); do perl -i -p -e 's/\r\n/\t\r\n/' ./$filename; done
The other solution would be to make a code modification for snmpenum.pl...
Cheers,
Morgan
The files containing the OID's that came with snmpenum (e.g. linux.txt) are in DOS format. Simply convert them to UNIX format (e.g. dos2unix) and it should work fine.
I'm trying to verify salted passwords with Perl and am stuck with unpack.
I've got a salted hashed password, e.g. for SHA256: SSHA256 = SHA256('password' + 'salt') + 'salt'
Base64 encoded that gets '
{SSHA256}eje4XIkY6sGakInA+loqtNzj+QUo3N7sEIsj3fNge5lzYWx0'.
I store this string in my user database. When a user logs in need to separate the salt from the hash to hash the supplied password with the salt and compare the result to the one retrieved from the db. This is where I'm stuck. I don't seem to have the right unpack template separate the hash (8-bit binary, fixed length, in this case 32 byte) from the salt (8-bit binary, variable length).
I have tried something like
my ($hash, $salt) = unpack('N32 N*', $data);
but that doesn't seem to work out.
My question is: How can I unpack this hash (after it has been Base64 decoded) to get the fixed length hash in one and the variable length salt in another variable?
I think you're needlessly re-inventing the wheel.
You could use e.g. Crypt::SaltedHash to easily verify it, for instance:
my $password_entered = $cgi->param('password');
my $valid = Crypt::SaltedHash->validate($salted, $password_entered);
A longer example, showing using Crypt::SaltedHash to generate the salted password in the first instance, too:
my $csh = Crypt::SaltedHash->new(algorithm => 'SHA-256');
$csh->add('secretpassword');
my $salted = $csh->generate;
# $salted will contain the salted hash (Crypt::SaltedHash picks random
# salt for you automatically)
# for example:
DB x $salted = $csh->generate;
0 '{SSHA256}H1WaxHcyAB81iyIPwib/cCUtjqCm2sxQNA1QvGeh/iT3m51w'
# validating that against the plaintext 'secretpassword' shows it's right:
DB x Crypt::SaltedHash->validate($salted, 'secretpassword');
0 1
# and trying it with an incorrect password:
DB x Crypt::SaltedHash->validate($salted, 'wrongpassword');
0 ''
No reason to re-invent all of this yourself.
You seem to be doing RFC2307 the hard way and also manage to introduce bugs. Those + do not mean what you think.
Subclass Authen::Passphrase::SaltedDigest instead.
Not sure the whole picture is present, but the unpack template you have specified -'N32 N*'- is for 32 unsigned long (32-bit) (big-endian) integers (see pack docs).
Looks like you may instead need unsigned chars: '32C C*'
I have these three lines in bash that work really nicely. I want to add them to some existing perl script but I have never used perl before ....
could somebody rewrite them for me? I tried to use them as they are and it didn't work
note that $SSH_CLIENT is a run-time parameter you get if you type set in bash (linux)
users[210]=radek #where 210 is tha last octet from my mac's IP
octet=($SSH_CLIENT) # split the value on spaces
somevariable=$users[${octet[0]##*.}] # extract the last octet from the ip address
These might work for you. I noted my assumptions with each line.
my %users = ( 210 => 'radek' );
I assume that you wanted a sparse array. Hashes are the standard implementation of sparse arrays in Perl.
my #octet = split ' ', $ENV{SSH_CLIENT}; # split the value on spaces
I assume that you still wanted to use the environment variable SSH_CLIENT
my ( $some_var ) = $octet[0] =~ /\.(\d+)$/;
You want the last set of digits from the '.' to the end.
The parens around the variable put the assignment into list context.
In list context, a match creates a list of all the "captured" sequences.
Assigning to a scalar in a list context, means that only the number of scalars in the expression are assigned from the list.
As for your question in the comments, you can get the variable out of the hash, by:
$db = $users{ $some_var };
# OR--this one's kind of clunky...
$db = $users{ [ $octet[0] =~ /\.(\d+)$/ ]->[0] };
Say you have already gotten your IP in a string,
$macip = "10.10.10.123";
#s = split /\./ , $macip;
print $s[-1]; #get last octet
If you don't know Perl and you are required to use it for work, you will have to learn it. Surely you are not going to come to SO and ask every time you need it in Perl right?