I read https://www.oasis-open.org/committees/download.php/13392/wss-v1.1-spec-pr-UsernameTokenProfile-01.htm and I know how to generate the Nonce and the Password. I have a doubt about UsernameToken wsu:Id.
What should be value of wsu:Id attribute.
Can it be default random one?
How can I generate it?
<wsse:UsernameToken wsu:Id="UsernameToken-1314D8CB1A76EFB5F614902572284093" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility">
<wsu:Created>2014.02.10T-09:12:00Z</wsu:Created>
<wsse:Username>Username</wsse:Username>
<wsse:Nonce EncodingType="UTF-8">KFIy9LgzhmDPNiqU/B9ZiWKXfEVNvFyn6KWYP+1zVt8=</wsse:Nonce>
<wsse:Password Type="wsse:PasswordDigest">CxWj1OMnYj7dddMnU/DrOhyY3j4</wsse:Password>
What should be value of wsu:Id attribute.
It can be a random sequence of characters (I noticed that even its length is arbitrary).
Can it be default random one?
As above, definitelly yes.
How can I generate it?
It's random, so use any inbuilt function which provide random string. For example (C#):
string usernameTokenId = $"UsernameToken-{Guid.NewGuid().ToString()}";
In my case I used not only wsu:Id="UsernameToken-..." but also wsu:Id="SecurityToken-..." and it was still working.
Related
I have tried with ModifyRequest but unfortunately I was not able to find the proper way.
I see it is very straightforward to do with DirectoryEntry but I must use the raw LdapConnection since it is the only way that allows authentication through client certificates.
If anyone has any solution or ideas, it would be great to discuss it.
I haven't really used LdapConnection as I usually use DirectoryEntry, however, I did write an article about how to work with security descriptor attributes, which might help you: Active Directory: Handling NT Security Descriptor attributes
I talked about getting the value from DirectoryEntry and DirectorySearcher. However, I suspect LdapConnnection will give you a raw byte array, in which case the section on Getting the value from DirectorySearcher may help you, since that shows how to create an ActiveDirectorySecurity object from a byte array. For example, if you have the byte array in a variable called byteArray, you can do this:
var adSecurity = new ActiveDirectorySecurity();
adSecurity.SetSecurityDescriptorBinaryForm(byteArray);
Then you can use adSecurity.GetSecurityDescriptorBinaryForm() to convert it back to a byte array before writing it back to AD.
I need to store a String of at least 2000 chars in the database, but i get the following validation message in Faktor-IPS:
Spalten-Size erreicht das Limit [1..255]
I found the PersistenceOptions in the .ipsproject-File and the attribute maxTableColumnSize - which is set to 255. If I change this value to 2000, all seems fine. Are there other effects if this value is changed or is this attribute only used for the validation?
The 'maxTableColumnSize' is only used for this validation and should be set according to your database implementation. Typical values can be found here: https://blog.faktorzehn.de/2021/06/faktor-ips-persistenz-optionen/?lang=en
My question is about this:
https://metacpan.org/pod/Crypt::OpenSSL::RSA
If there described method verify() fails, I do error handling like this:
my $rsa_pub = Crypt::OpenSSL::RSA->new_public_key($x509PubKey);
logm("exception: my err msg...") unless $rsa_pub->verify($text, $signature);
But is it possible get exact reason why verification failed?
I'm not sure that getting "the exact reason why verification failed" makes sense as a question. To verify a signature you specify:
the signature algorithm
the padding algorithm
the hashing function
Ultimately the signature is just a number that was computed by padding the the plaintext input, hashing the resulting bytes and performing a mathematical calculation using the private key.
Verifying the signature involves taking the plaintext, padding it, hashing it, and performing a mathematical calculation using the public key to produce another number which is then compared to the number from the signature (using modulo arthimetic?). If the numbers are the same then the signature is valid if they're different, it's not.
All of which is a roundabout way of saying if the verify method returns false then assuming you're using the correct public key, one of these things must be different:
the plaintext
the signature algorithm
the padding algorithm
the hashing function
But there's really no way of knowing which. It's like saying "I'm trying to multiply two numbers to get 42, but I don't get 42, which of the numbers is wrong?".
Here are a couple of signature verification functions for common combinations of algorithms (which I wrote for Authen::NZRealMe::XMLSig):
sub _verify_signature_rsa_sha1 {
my($self, $plaintext, $bin_sig) = #_;
my $rsa_pub_key = Crypt::OpenSSL::RSA->new_public_key($self->pub_key_text);
$rsa_pub_key->use_pkcs1_padding();
$rsa_pub_key->use_sha1_hash();
return $rsa_pub_key->verify($plaintext, $bin_sig);
}
sub _verify_signature_rsa_sha256 {
my($self, $plaintext, $bin_sig) = #_;
my $rsa_pub_key = Crypt::OpenSSL::RSA->new_public_key($self->pub_key_text);
$rsa_pub_key->use_pkcs1_oaep_padding();
$rsa_pub_key->use_sha256_hash();
return $rsa_pub_key->verify($plaintext, $bin_sig);
}
The context for the above code is signed sections of XML documents, which has the added complexity of needing to use the right canonicalization and encoding and also the signature data is Base64 encoded so needs to be decoded into bytes first.
The information about which padding and hashing algorithms to use should be available from the spec for the source data you're working with, but if not I guess you could try random combinations.
Im working on a script to hash a "fingerprint" for communicating with the secure Pay Direct Post API.
The issue I have is im trying to create a SHA-1 String that matches the sample code provided so that i can ensure things get posted accurately.
the example Sha-1 string appears encoded like
01a1edbb159aa01b99740508d79620251c2f871d
However my string when converted appears as
7871D5C9A366339DA848FC64CB32F6A9AD8FCADD
completely different...
my code for this is as follows..
<cfset variables.finger_print = "ABC0010|txnpassword|0|Test Reference|1.00|20110616221931">
<cfset variables.finger_print = hash(variables.finger_print,'SHA-1')>
<cfoutput>
#variables.finger_print#
</cfoutput>
Im using Coldfusion 8 to do this
it generates a 40 character hash, but i can see its generating completely different strings.
Hopefully someone out there has done this before and can point me in the right direction...
thanks in advance
** EDIT
The article for creating the Hash only contains the following information.
Example: Setting the fingerprint Fields joined with a | separator:
ABC0010|txnpassword|0|Test Reference|1.00|20110616221931
SHA1 the above string: 01a1edbb159aa01b99740508d79620251c2f871d
When generating the above example string using coldfusion hash it turns it into this
7871D5C9A366339DA848FC64CB32F6A9AD8FCADD
01a1edbb159aa01b99740508d79620251c2f871d
Sorry, but I do not see how the sample string could possibly produce that result given that php, CF and java all say otherwise. I suspect an error in the documentation. The one thing that stands out is the use of "txnpassword" instead of a sample value, like with the other fields. Perhaps they used a different value to produce the string and forgot to plug it into the actual example?
Update:
Example 5.2.1.12, on page 27, makes more sense. Ignoring case, the results from ColdFusion match exactly. I noticed the description also mentions something about a summarycode value, which is absent from the example in section 3.3.6. So that tends to support the theory of documentation error with the earlier example.
Code:
<cfset input = "ABC0010|mytxnpasswd|MyReference|1000|201105231545|1">
<cfoutput>#hash(input, "sha-1")#</cfoutput>
Result:
3F97240C9607E86F87C405AF340608828D331E10
I have some strings and some hashes of them, but I don't know which hash function is used. Any idea?
String hash
NN34W f8b46bcdc3b3c92
EM3M3 d8015ca876fd051
HXDKD a740e97464e5dfe
AKREJ aa7aa2dadfcbe53
3bNMK 0f11440639191d9
Edit:
Thank for answers, it's a hash of the captcha.
https://registracia.azet.sk/
If you check URL of captcha image, on the end is HASH value. This
On the server are send in HTTP POST are send TEXT: (P92M4) and HASH (72fec89a2e0ade2) and other values.
I like know how comptute hash of the TEXT P92M4, and control with HASH value, which is send on server.
Because I like make own captcha system for my school project, so I first analyzing situation and weakness.
As I understand your situation, a POST request sends both the "text" and the "hash" to the CAPTCHA server. This then uses whatever hash function they use to hash your text, checks to see if it matches the hash, and decides whether or not you succeeded. Presumably, the server sends you the image, as well as the hash, and then you enter the text.
As such, if you figured out the hashing function, you'd have completely broken this CAPTCHA system: All you would need to do is hash any string using their hashing function, and then when sending your POST request, ignore the hash they sent you and merely send them your computed text and hash pair. Thus, you could very easily automate successfully passing the CAPTCHA challenge.
To illustrate how difficult "reversing" the hash might be, consider the following hash that they very well might use:
Split the TEXT up alternating letters: thus ABCDE becomes ACE and BD
md5 the two halves using salts "fj49w0utw4a" and "r8h3wlsd"
md5("fj49w0utw4a"."ACE") is 115c05f0e5300f958ba01caa64b989f
md5("r8h3wlsd"."BD") is 74eecae86ef46382eb95443a1b1fa8f5
Take every 3rd char of the first string and every 4th char of the second, and alternate them until you have 15 chars
115c05f0e5300f958ba01caa64b989f becomes 55e09b1ab9
74eecae86ef46382eb95443a1b1fa8f5 becomes e8425af5
Final hash value for "ABCDE": 5e58e40295ba1fa
There is really no way you are ever going to reverse engineer that.
UPDATE
Note that CAPTCHAs as described above (and implemented on that site) are extremely insecure, as they only require one valid text/hash combination to be known
To demonstrate, use Firebug or equivalent and navigate to the CAPTCHA area of the form. We will be editing some hidden values.
Change the form[captcha_url] value from https://pokec.azet.sk/sluzby/system/captcha/[somehash] to https://pokec.azet.sk/sluzby/system/captcha/ee2be1f239e5d17
Change the form[captcha_hash] value from [somehash] to ee2be1f239e5d17
Regardless of what the picture says, type "P22KD" for the CAPTCHA
There are several ways to mitigate this vulnerability. As Tangrs suggested, you can store the hash value in a session variable so that it cannot be manipulated by the client. Less elegant but also effective is to store the submitted CAPTCHA in a database and not allow duplicate CAPTCHAs, as is implemented on the link in the question. This is fine, until you start running out of unused CAPTCHAs and end up getting collisions.
Seems smaller than any industry hash... possibly it's propriety?
A bit more info would help though, what language, where did you get it from?