We have Lotus Notes signed document and user's public key.
What we need to do: enter the key into a field in a special application (it can be Lotus notes database or some special soft). Then we ask this special application: "Is this document really signed by this user with this public key?"
And our app must answer: yes or not.
We try to write this special application and we met few issues:
We have field named $Signature in the document, that is the hash of signed fields, encrypted with private key of the signer. I can see content of this field in document's properties. But I can't to extract it programmatically (I tried LotusScript and Java). And I didn't find any way to do it.
Therefore I just manually copied content of this field and pasted it into a field on a special form to further analyze. But there I met another problem. I don't know how to decrypt this signature. What algorithm Lotus uses to sign hash? If I will know the algorithm I guess I will be able to decrypt it with Java and get hash of signed fields.
And there will be one more problem I believe. I dont know how Lotus counts hash of fields. Does it use md5? I need to know it to be able to compare hashes and say did this user signed the document or not.
So. It's the interest task. But now it's impossible to solve it. There are 3 huge problems on the way. Can anyone help with them?
The answer is: don't try to do this yourself. Not the way you described it. There's an API to validate Notes signatures.
Just copy the document's UNID to your database, and then write code using the Notes C API to open the document and call the API function NSFNoteVerifySignature() to validate it. You can do this from Java using JNI or from LotusScript by following the techniques that are described here, or you can use the LSX toolkit, or just write a standalone C program.
You would have to use the Notes C API anyhow to deal with two of the three points that your raised:
You need the C API to get get at the contents of the $Signature item.
The signature is RSA.
You actually have two problems: the algorithm, and the input. You have to match them both. If I recall correctly, Lotus has described the hash algorithm as "modified MD2". Bear in mind, this goes back well over 20 years, and breaking compatibility is something that they don't like to do. It's possible that they've changed it when they upgraded RSA key sizes, but I don't recall hearing about that. But as I said, that's only half the problem. You need to get the raw input bytes in exactly the same format as the signature algorithm saw them, and for rich text fields this probably means reading raw CD records, which requires the C API.
Related
Scenario: I need to store document accepted by the customer in my database. Customer needs to be sure that I don't modify it through time, and I need to have possibility to prove that stored document was accepted by the customer.
Do you know proven ways how to achieve this without doubts from any side?
I think I can create checksum from stored data for the customer, but I need to ensure that this checksum is unmodifiable by the customer. Any ideas?
PS. If you have better idea how to title this question then tell me, please.
PS. Let me know if you see better forum to ask this question, please.
What we call this in Cryptography is data integrity.
To ensure that the data is not changed by you or someone else, your customer can calculate the hash of the file with a cryptographic hash functions, which are designed to have collision resistance. I.e.
Hash(Original) != Hash(Modified) // equality almost impossible
In short, when you modify it is expected that the new modified document has the same hash value is impossible (in Cryptology term, negligible).
Your customer can use SHA-3 hash function which is standardized by NIST.
Don't use SHA-1 which has shattered.
If you want to go further, your customer can use HMAC which are key-based hash functions which supply data integrity and the authentication of data.
For the second part, we can solve it by digital signatures. Your customer signs the message
Sign(hash(message))
and gives you
( Sign(hash(message)), message ) )
and his public key.
You can verify the signature with the public key of the customer to see that the customer changed the data or not. Digital signatures gives us Non-Repudation.
This part actually solves your two problems. Even third parties can check that the data is not modified and comes from the signer (your customer).
Note : don't use checksums which are not Cryptographically secure and mostly easy to modify the document in a way that they have the same checksums.
Based on what i know (correct me if i am wrong) the 'access_token' is equivalent to the 'protected ticket' field in AspNetUser table. It's just hashed.
What i am planning to do is deserialize the protected ticket to get the access_token value.
I am trying to support a SSO scenario wherein, the user can access multiple application using the same access token.
Unfortunately, if the hash function used is a cryptographic hash, which the circumstances suggest, this is definitionally impossible (or should be...). Cryptographic hash functions are designed to be extremely expensive (ideally impossible) to reverse, and so the most effective method you have would be to attempt to brute-force the hash, I.e. running inputs through the hash function until you get one that produces the output you want. Even then, there's no telling how long it would take you to find it. It is strongly recommended not to write anything that depends on routinely brute-forcing a cryptographic hash.
Of course, its possible that the possible inputs are incredibly small (I.e. at most 16 bits or so), or that the function used is not a cryptographic hash function (I.e. its something like base64 encoding or rot-13). In that case, you might have a method to reverse the "hash" efficiently.
However, I strongly suspect that is not the case. In this endeavour, I think you are simply out of luck, and will have to find another way to get the functionality you desire.
I think I'm a bit late, but it should be possible. The data of ProtectedTicket will be secured by Microsoft.Owin.Security.ISecureDataFormat.Protect. It's not a one way hash. So it can be reversed. You can look this up on Github in the Katana project (Microsoft's Owin implementation):
https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Security/DataHandler/SecureDataFormat.cs
As you can see, this interface provides a method Unprotect also. Didn't test it, but you could give it a shoot.
you can use the same token on the same apps as long the jwt token is signed with the same credentials (audience and secret) on every app. This allows every app to verify that the token is valid. this means, how-ever, that every app must know audience id and secret in the backend
please i have a web application developed using asp.net which generates certificates (pdf files) using data in xml files. What can i include (e.g like using a barcode or something) to make the certificates authentic to make it impossible to forge or clone. I have been on this for like a week now. Google hasn't been helpful either. Please assist.
thanks
I can explain how to achieve this, but as is customary on SO, you'll have to write the code yourself.
You are creating a PDF file based on XML data. When the document is printed, you can't use a digital signature as digital signatures check the validity of the document at the byte level: a hash is created of the document, this hash is signed with a private key (some extra stuff is added) and that signed hash is integrated into the file.
Now when somebody wants to check the integrity of the file, a new hash of the bytes in the file is created (hash #1) and the encrypted hash is decrypted (hash #2) using the public key that corresponds with the private key that was used to encrypt the hash. If hash #1 differs from hash #2, the document was forged.
When you print a document, there are no bytes to check. As Chris Haas points out, you can't protect the document. However: you can protect the data. For instance, you could add the original XML to the document in the form of a 2D barcode (you can choose which type of barcode). This way, people can scan the original data. You can then add a second barcode. For instance: you make a hash of the original XML and you encrypt it with a private key. You add this encrypted hash as a barcode (you may have to use Base64 encoding).
Now when somebody has scanned the first barcode for the data, he can scan the second barcode for the "signature". He needs to decrypt the scanned signature using the public key and compare the resulting hash with a hash of the scanned data. If both hashes are identical, the scanned data equals the original data.
We are using the System.Web.Security.DefaultMembershipProvider on our project and we’ve hit a wall.
This particular implementation of the MembershipProvider contract uses a hard coded model definition (System.Web.Providers.ModelHelper.membershipSsdl and Sytem.Web.Providers.ModelHelper.membershipCsdl) to create the model and resulting database using EntityFramework.
This particular model definition sets the max length of the UserName field to 50 characters and the max length of the Email field to 256 characters. Now in a lot of scenarios our users may want to/be required to user their email address as their username. Clearly this won’t be possible for a lot of them as the data validation within this model will fail.
From what I can see there is no way to override this model definition, and the source code to the ASPNET Universal Providers library is not available on CodePlex as part of the Microsoft Open Source program. However, resharper in visual studio will perform a good amount of decompilation that allows us to see the inner workings of the implementation.
At this juncture we are resigned to going down the ‘implement your own membership provider’ route, but I/we wanted to see if anyone out there had any advice/alternative thoughts/suggestions around this problem. Otherwise it looks like we are going to duplicate several thousand lines of existing MS code just to change a couple of characters.
For anyone that is interested in this issue, we decided against rolling our own provider datastore and simply hid the usage of the username field away from the end user. Their email address was used as their 'username' but internally we actually stored a guid in the username field and wrote some code to internally translate from email to 'username' before performing things like authentication. Not great, but it got us over the line.
I was hoping someone could help me sort something out. I've been working on a shopping cart plugin for WordPress for quite a while now. I started coding it at the end of 2008 (and it's been one of those "work on it when I have time" projects, so the going is very slow, obviously!) and got pretty far with it. Even had a few testers take me up on it and give me feedback. (Please note that this plugin is also meant to be a fee download - I have no intention of making it a premium plugin.)
Anyway, in 2010, when all the PCI/DSS stuff became standard, I shelved it, because the plugin was meant to retain certain information in the database, and I was not 100% sure what qualified as "sensitive data," and I didn't want to put anything out there that might compromise anyone, and possibly come back on me.
Over the last few weeks, some colleagues and I have been having a discussion about PCI/DSS compliance, and it's sparked a re-interest in finally finishing this plugin. I'm going to remove the storage of credit card numbers and any data of that nature, but I do like the idea of storing the names and shipping addresses of people who voluntarily might want to create an account with the site that might use this plugin so if they shop there again, that kind of info is retained. Keep in mind, the data stored would be public information - the kind of thing you'd find in a phone book, or a peek in the record room of a courthouse. So nothing like storing SS#'s, medical histories or credit card numbers. Just stuff that would maybe let someone see past purchases, and retain some info to make a future checkout process a bit easier.
One of my colleagues suggested I still do something to enhance security a bit, since the name and shipping address would likely be passed to whatever payment gateway the site owner would choose to use. They suggested I use "one-way encryption." Now, I'm not a huge security freak, but I'm pretty sure this involves (one aspect anyway) stuff like MD5 hashes with salts, or the like. So this confuses me, because I wouldn't have the slightest idea of where to look to see how to use that kind of thing with my code, and/or if it will work when passing that kind of data to PayPal or Google Checkout, or Mal's, or what have you.
So I suppose this isn't an "I need code examples" kind of question, but more of a "please enlighten me, because I'm sort of a dunce" kind of question. (which, I'm sure, makes people feel much better about the fact that I'm writing a shopping cart plugin LOL)
One way encryption is used to store information in the database that you don't need back out of the database again in its unencrypted stage (hence the one-way moniker). It could, in a more general sense, be used to demonstrate that two different people (or systems) are in possession of the same piece of data. Git, for instance, uses hashes to check if files (and indeed entire directory structures) are identical.
Generally in an ecomm contect hashes are used for passwords (and sometimes credit cards) because as the site owner, you don't need to retain the actual password, you just need a function to be able to determine if the password currently being sent by the user is the same as the one previously provided. So in order to authenticate a user you would pass the password provided through the encryption algorithm (MD5, SHA, etc) in order to get a 'hash'. If the hash matches the hash previously generated and stored in the database, you know the password is the same.
WordPress uses salted hashes to store it's passwords. If you open up your wp_users table in the database you'll see the hashes.
Upside to this system is that if someone steals your database, they don't get the original passwords, just the hash values which the thief can't then use to log in to your users' Facebook, banking, etc sites (if your user has used the same password). Actually, they can't even use the hashes to log in to the site they were stolen from as hashing a hash produces a different hash.
The salt provides a measure of protection against dictionary attacks on the hash. There are databases available of mappings between common passwords and hash values where the hash values have been generated by regularly used one way hash functions. If, when generating the hash, you tack a salt value on to the end of your password string (eg my password becomes abc123salt), you can still do the comparison against the hash value you've previously generated and stored if you use the same salt value each time.
You wouldn't one way hash something like an address or phone number (or something along those lines) if you need to use it in the future again in its raw form, say to for instance pre-populate a checkout field for a logged in user.
Best practices would also involve just not storing data that you don't need again in the future, if you don't need the phone number in the future, don't store it. If you store the response transaction number from the payment gateway, you can use this for fraud investigations and leave the storage of all of the other data up to the gateway.
I'll leave it to others to discuss the relative merits of MD5 vs. SHA vs ??? hashing systems. Note, there's functions built in to PHP to do the hashing.