I am facing the problem of generate the same SHA256 hash of the password as stored in primavera's database in users table.
Every sha256 hash generator I found make the same SHA256 hashes between them but different from priavera's one!
I need to integrate our custom application with primavera so I want to use primavera's users/password to make authentication of the users. Theoretically I need to get user's password, calculate the sha256 hash and compare it with the primavera's hash.
But as I can see there is not really SHA256 hash or primavera uses some password salt stuff.
Is any body know, how exactly primavera calculates password hashes?
It isn't a straight sha256 hash - that would be too easy. P6 can authenticate through other mechanisms as well as their native one and could change their algorithm whenever they want.
I would advise authenticating to P6 through either the P6 java api or web services. This will protect you against Primavera changes to their authentication algorithms, decouple you from changes to how your company authenticates with P6 (e.g. native or AD/LDAP) and also allow you to delegate p6 access to p6 rather than working that out as well.
Bottom line - if you want to integrate your custom application with P6 then use the P6 integration apis.
Related
Question: Is there a technical explanation how client side code-signing can be used in enterprise enviroments with open source tools like signtool or openssl?
In my usecase, I want to create a hash of a code file and sent the hash on a seperate server. This server is just used for signing. On this server are also the certificates and private keys stored.
After the hash is signed, I want to transfer the signed hash back to the client and envelope the signed hash with the code file e.g. a .exe file.
In the "Mircosoft Code Signing Best Practices", it's also recommended to first create a hash of the data and then sign the hash value with a private key.
Unfortunately I can't find any further informations how to implement this with seperate steps, described as abow.
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
"In practice, using public-key algorithms to directly sign files is inefficient. Instead, typical code-signing procedures first create a cryptographic hash of the data in a file—also known as a digest—and then sign the hash value with a private key. The signed hash value is then used in the digital signature. The digital signature can be packaged with the data or transmitted separately. A separately transmitted digital signature is known as a detached signature."
I need to store a password's SHA-256 hash in OrientDB REST function - so I can use it to authenticate the user. The incoming call to the REST function will contain the password (over HTTPS) but I want to generate a hash and store that instead of the password itself.
However, OrientDB does not expose any helpers to do this. And straight javascript does not have helpers to do this either... any way I can make this happen?
(one obvious option is to SHA-256 it in the middle tier and pass that to OrientDB but I'd rather keep this in the database tier)
You can use OSecurityManager from Javascript functions like this
return com.orientechnologies.orient.core.security.OSecurityManager.instance().digest2String("password");
I'm making a forget password feature in my web app, problem is I store user's password using:
Hash::make('_their_password_')
Is there any way to re-hash it back or any recommended approach for this?
The point of hashing a password is that it's (supposed to be) an irreversible operation. If your database is compromised, the attacker will gain access to the hashes, but not to the passwords. That way the attacker can't log in with the users' passwords on other sites.
Make a "we'll reset your password" feature instead of a "we'll send you your password" feature.
Note that there are also other best practices you absolutely should be following regarding password hashing, to make sure the "supposed to be" above actually holds, and to further minimize the impact if your site is compromised. Laravel's Hash class seems to already be using the password-appropriate hash function Bcrypt. However, make sure you're using a salt when you're hashing your password.
The Laravel's Hash method cannot be reversed.
One way encryption is the best way to store user passwords, or other sensitive data.
One way means that your data can be converted into an encrypted string, but due to a complex algorithm with painful maths, reversing the process is not possible. This makes storing passwords a doddle! Your customers don't have to worry about you knowing their passwords, but you are still able to compare them (by hashing the password they provide) or change the password if needed.
If you need to reverse, you can use Crypter class.
$secret = Crypter::encrypt('I actually like Hello Kitty');
$decrypted_secret = Crypter::decrypt($secret);
Read more about encryption here http://codehappy.daylerees.com/encryption
If you want to verify the content of password with other value use the following.
return Hash::check($value, auth()->user()->password);
In case of claim based authentication which uses SSO, an application receives a token from the issuer for a particular user and that token contains the claims as well as some sort of digital signature in order to be traced by the application that an issuer is a trusted one.
I want to know, if there are some sort of algorithms involved by which this application recognizes an issuer?
I had read that issuer has a public key and all the other applications have their own private key, is it true?
There are many protocols, formats and methods of doing Single Sign On such as Security Assertion Markup Language (SAML), OpenID and OAuth. The goal is for one entity, such as a website, to identity and authenticate the user (such as through a user name and password) and other entities, such as other websties, trust the evidence of that authentication through a token. This means users need not remember yet another password and each website maintain their own list of passwords.
This trust is usually enforced through cryptography using a digital signature. Digital signatures are used because it allows the trusting entity to verify token was (1) issued by the authenticating entity only and (2) not tampered with without being able to impersonate (pretend to be) the authenticating entity.
As you say above, this is performed using asymmetric or public key cryptography. Symmetric cryptography, such as the AES or DES algorithms, use a single key to encrypt and decrypt data. Asymmetric cryptography, such as the RSA algorithm, uses two related keys. Data encrypted using one can only be decrypted by the other and vice versa.
One key is usually kept secret, called the private key, and the other is distributed widely, called the public key. In the example above, the authenticating entity has the private key that allows it to encrypt data that anyone with the public key can decrypt.
It would seem to follow that the authenticating entity would just encrypt the user details and use that as the token. However, commonly used asymmetric algorithms like RSA are very slow and encrypting even small amounts of data can take too long.
Therefore, instead of encrypting the user details, the authenticating entity generates a "hash" or "digest" and encrypts that. A hash algorithm converts a piece of data into a small number (the hash) in a very difficult to reverse way. Difference pieces of data also create different hashes. Common hash algorithms include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) and its derivatives like SHA1, SHA256 and SHA512.
The hash encrypted with the authenticating entity's private key is called a digital signature. When it receives the token, the trusting entity decrypts the token using the authenticating entity's public key and compares it to a hash it calculates itself. If the hashes are the same, the trusting entity knows it has not been modified (because the hashes match) and it must have come from the authenticating entity (because only it knows its private key).
If you want more information about SAML and claims-based authentication, I found this video very helpful. It does get complicated rather quickly and you may need to watch it multiple times but Vittorio covers most of these concepts in great detail.
What is the Difference between a Hash and MAC (Message Authentication code)?
By their definitions they seem to serve the same function.
Can someone explain what the difference is?
The main difference is conceptual: while hashes are used to guarantee the integrity of data, a MAC guarantees integrity AND authentication.
This means that a hashcode is blindly generated from the message without any kind of external input: what you obtain is something that can be used to check if the message got any alteration during its travel.
A MAC instead uses a private key as the seed to the hash function it uses when generating the code: this should assure the receiver that, not only the message hasn't been modified, but also who sent it is what we were expecting: otherwise an attacker couldn't know the private key used to generate the code.
According to wikipedia you have that:
While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To be considered secure, a MAC function must resist existential forgery under chosen-plaintext attacks. This means that even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the attacker's choosing, the attacker cannot guess the MAC for other messages without performing infeasible amounts of computation.
Of course, although their similarities, they are implemented in a different way: usually a MAC generation algorithm is based upon a hash code generation algorithm with the extension that cares about using a private key.
A hash is a function that produces a digest from a message. A cryptographically secure hash is for which it is computationally infeasible to generate a message with a given digest. On its own a hash of a message gives no information about the sender of a given message. If you can securely communicate the hash of a message then it can be used to verify that a large message has been correctly received over an unsecured transport.
A message authentication code is a way of combining a shared secret key with the a message so that the recipient of the message can authenticate that the sender of the message has the shared secret key and the no-one who doesn't know the secret key could have sent or altered the message.
An HMAC is a hash-based message authentication code. Usually this involves applying a hash function one or more times to some sort of combination of the shared secret and the message. HMAC usually refers the the algorithm documented in RFC 2104 or FIPS-198.
A MAC does not encrypt the message so the message is in plain text. It does not reveal the secret key so a MAC can be sent across on open channel with out compromising the key.
Found this to the point answer from another forum.
These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"):
Integrity: Can the recipient be confident that the message has not been accidentally modified?
Authentication: Can the recipient be confident that the message originates from the sender?
Non-repudiation: If the recipient passes the message and the proof to a third party, can the third party be confident that the message originated from the sender? (Please note that I am talking about non-repudiation in the cryptographic sense, not in the legal sense.) Also important is this question:
Keys: Does the primitive require a shared secret key, or public-private keypairs? I think the short answer is best explained with a table:
Cryptographic primitive | Hash | MAC | Digital
Security Goal | | | signature
------------------------+------+-----------+-------------
Integrity | Yes | Yes | Yes
Authentication | No | Yes | Yes
Non-repudiation | No | No | Yes
------------------------+------+-----------+-------------
Kind of keys | none | symmetric | asymmetric
| | keys | keys
Please remember that authentication without confidence in the keys used is useless. For digital signatures, a recipient must be confident that the verification key actually belongs to the sender. For MACs, a recipient must be confident that the shared symmetric key has only been shared with the sender.
Click here for more info
HASH FUNCTION: A function that maps a message of any length into a fixed length hash value, which serves as the authenticator.
MAC: A function of the message and a secret key that produces a fixed length value that serves as the authenticator.
A Hash is a summary or a finger print of a message and provide neither integrity nor authentication itself, as is it is susceptible to man-in-the-middle attack. Suppose A wants to send a message M, combined with hash H of M, to B. Instead C capture the message and generate Message M2 and hash H2 of M2, and sends it to B. Now B, by no mean can verify whether this is the original message from A or not. However, hash can be used in some other ways to achieve integrity and authentication, such as MAC.
A MAC which is also a summary of the message provide Integrity and Authentication. MAC can be computed in many ways. The simplest method is to use a hash function with two inputs, the message and a shared secret key. The use of the shared secret key adds the Authentication ability to the MAC, and thus provide integrity and authentication. However, MAC still does not provide non-repudiation, as any of the party(es) having the shared secret key can produce the message and MAC.
Here comes the Digital Signature and Public Key Cryptography in action.
Basically the main difference is MAC uses a private key and hash does not use any keys. Because of that MAC allows us to achieve authentication.
Hash functions utilize asymmetric cryptography whereas, MAC use symmetric cryptography.
Cryptographic hash functions are not always a MAC, but MAC can be a cryptographic hash functions (keyed hash functions).
Hash functions provide non-repudiation where MAC do no provide non-re