I have transactions which are held for verification and approval (prior capture). When i approve them in the merchant portal, silent post receives an immediate update, but the MD5 hash doesn't match. It seems that it's being built differently by authnet. For all other transactions (arbs and one-times) the hash matches fine.
Is there a different md5 structure for prior-capture approvals? is it documented anywhere?
Related
I am using forgot password to change my GitHub password, but it's required 2FA credentials and I lost the 2FA app as well. So is there any I can change my password without using 2FA credentials?
A list of possibilities is given in this help page on GitHub.
To summarize, you can recover your account on your own, even after losing your 2FA app, if you (already) have:
A recovery code: you can download and safely keep a list of backup codes for situations like this.
A fallback number: a second phone number associated with your account.
A security key: you can have, for example, a physical USB stick as a security key.
Without this, there are two more methods provided, but will take longer and are not guaranteed to recover your account:
Using a verified device, SSH token, or personal access token: you can apply for account recovery by proving that you are logging in from a device you have used before, or using a SSH or personal access token that has been used before. The request will be then manually considered by GitHub support.
Using an account recovery token on Facebook (if you have set it previously): This also requires manual verification.
In general, to avoid such issues in the future, it would be advisable to download (and perhaps print a physical copy) of recovery codes for each service you use 2FA with, as that would be one of the easiest and fastest ways to recover your account.
I've used password_hash($pwd, PASSWORD_BCRYPT) to create a hash and store in the user table. It will be used for login verification.
Since hashing is a one way function,
My question is can I use the same hash as the account verification code in the activation email send to user.
Will it compromise security since knowing the hash doesn't reveal the password.
Yes, it would compromise security because an attacker with access to the email account (either presently or at any future point in time if the email is never deleted), could run a password guessing attack on the hash.
If would be better to generate a 128-bit key using a CSPRNG, this can be emailed to the user as is. On the server-side you would want to hash this using SHA-2 for storage, because that way if your activation table data was ever exposed, an attacker could not activate accounts that do not have valid email addresses. Note that no salt is needed for automatically generated keys of this strength.
This approach is fairly simple, and mitigates the risk in sending the password hash directly.
I don't understand the point of having access token in authentication. Below is a paragraph of explanation I took but I still confused. Since every api call still go to the db look for the token, what's the different check for the username and password for every http request?
Instead of forcing clients to send username and password with every
request you can have a "get_access_token" function in your RESTful
service that takes the username and password and responds with a
token, which is some sort of cryptographic hash that is unique and has
some expiration date associated with it. These tokens are stored in
the database with each user. Then the client sends the access token in
subsequent requests. The access token will then be validated against
the database instead of the username and password.
Using the access token limits the amount of time the username and password are being used and sent across the wire.
How many times do you want your username and password, SSN, or other sensitive data do you want being stored and transmitted? Do you want that on every request?
First of all, access tokens are typically validated by checking the digital signature, which does not require the receiving service to talk to the issuing server. The client gets an access token once and uses it until it expires.
But even if the token had to be checked against the database on every call (when using reference tokens for example), tokens are still preferred over sending username and password on each call. They remove the need for the client to keep the password in memory (or elsewhere), where it can easily be stolen.
(1) Access token is less sensitive than your password. Access tokens typically expire after a short time (this is a requirement in the Oauth threat model), whereas passwords tends to be long term. If somebody grabs your access token, there is limited damage they can do. If they grab your password, then there is a lot of damage that they can do. Especially if you use the same or related passwords on multiple sites.
(2) If the server implemented password verification securely, then they should be using a slow function like PBKDF2, bcrypt, or scrypt to validate your passwords. These functions are designed to be slow so that if somebody gets access to the database, they will not be able to reverse many passwords: see Our password hashing has no clothes. Given that password checking is supposed to be slow, we don't want to be doing it often! Validation of access tokens is much quicker however.
(3) The system that grants you access to a resource ("resource provider") might not be the same as the system that checks your identity ("identity provider"). For example, many websites including StackOverflow allow you go login with your gmail account. In this case, Google is the identity provider and StackOverflow is the resource provider. Would you really want to provide your gmail password to StackOverflow? I hope not.
I have been looking into REST authentication schemes (many discussed on SO), and many of them seem to be overly complex for my purposes. I have formulated a simpler scheme from elements of the more complex ones: but I would like to know if there are any security holes in my approach.
Influencing factors:
TLS everywhere is too slow and resource heavy
I do not require security against eavesdropping as all information is public.
Proposed authentication scheme:
"Sign up" and "Login" are achieved via a TLS connection. On Login, a username and password are supplied and a shared secret key is returned by the server (and then stored in local storage by the client e.g. HTML5 local storage, App storage, etc).
Every other request takes place over cleartext HTTP
Client side algorithm:
Before sending, every request is "salted" with the shared secret key and an SHA hash is taken of the salted request.
This hash is inserted into the request in a custom HTTP header.
The salt is removed from the request.
The request is sent with the custom header.
Server side algorithm:
Server isolates and removes the custom Hash header from the request.
Server salts the request string with the shared secret key.
Server takes the hash of the salted request and compares it to the value of the custom hash header.
If they are the same, we have identified which user sent the request and can proceed with authorisation etc based on this knowledge.
Are there any vulnerabilities in this scheme that I have overlooked?
I would question your assumptions here.
TLS everywhere is too slow and resource heavy
TLS is becoming almost ubiquitous for APIs and one reason is because it is now relatively cheap for both clients and servers to support it. How much overhead? As usual "it depends" but certainly negligible enough for most modern APIs, even mass-consumer APIs like Facebook and Twitter, to be moving towards using it exclusively.
I do not require security against eavesdropping as all information is public.
This is a common myth about TLS. Even for public data, consider the implications:
Any intermediary agent can inject their own requests and responses. It could be junk, malicious, subtly incorrect, whatever. Secure communication is not just to keep the content private, it's also to maintain its integrity. (A common example is telcos and hotels injecting ads into websites.)
The data may be public, but the traffic may still be sensitive. What if you could monitor Apple's Wikipedia requests? Would it be interesting if there was a spike in requests to car-related articles? Without TLS, intermediaries can monitor requests a user is making.
None of which critiques your algorithm. You could ask on Cryptography Stack, but it's considered fairly risky to roll your own authentication and rarely worth it nowadays.
What you are describing is an MAC based authentication scheme. Instead of rolling your own implementation, you should look at Hawk or AWS authentication schemes.
A downside of such an authentication scheme is that the server that needs to validate the request needs to talk to the authentication server to get the secret key. This impacts the scalability of the system in a negative way.
Token based authentication schemes can validate the request without going back to the token issuing authority due to digital signatures.
Finally, I agree with #mahemoff that TLS is becoming ubiquitous and very cheap. Actually, depending on the circumstances, HTTPS may outperform HTTP.
I'd like to make requests from an iphone app to a web service I've built. How can I verify that requests made to the web service come from my iphone app (or indeed any authorised source) and are not forged?
I have looked at basic auth over HTTPS but is baking credentials into an application secure?
This question isn't really iphone specific; I'd like to know how to protect and authenticate requests in general.
Authentication can be asserted by presenting something you know, something you have, something you are or a combination of the three.
The iPhone doesn't have retinal or fingerprint scanners, so there are no "something you are" options available.
Client certificates work well as a "something you have" token. Most smartcards work by signing a message with an embedded certificate. When a certificate is compromised, it can be put onto a Certificate Revocation List (CRL) referenced by the webservers. Obviously, you wouldn't want to put your app's embedded certificate in the CRL -- that would deny access to all your users. Instead, you'll want users to download individual certificates to their iPhone.
After that, it's a matter of monitoring for unusual behavior to find the bad actors and adding those certs to the CRL. Two dead giveaways would be clients who send too many requests at once or from too many different IPs in too short a time.
Login/password is a simple "something you know" token. Like certificates, login/password combinations can be compromised and similar monitoring can be set up to find inappropriate behavior. The difference is compromised accounts would be marked "blocked" rather than added to a CRL.
By requiring both a client certificate and a login/password you increase the amount of effort needed to compromise an account.
Of course, you must ensure only valid accounts are added to the database. If there is an automated way to create new accounts and corresponding client certificates, then that account creation server/process becomes the easiest way for bad actors to create viable, unauthorized accounts. Requiring a real person to sign-off on accounts removes the automation process, but means a disgruntled or corrupt employee could create invalid accounts. Requiring a second person to counter-sign the account makes it harder for a single person to be an inside threat.
In short, ensuring high integrity of the clients is a process that can be made arbitrarily complex and expensive. What tools and processes you decide to deploy as the authentication scheme has to be balanced by the value of what it is protecting.
In theory, if you want the connection to be secure, the best is to have the client sign their request using a certificate. There are multiple resources about this. Look for "client certificate" on Google.
This example from Sun is in Java, but the concept is similar whatever the language.
PS: obviously, this doesn't prevent you from using other authentication methods such as passwords, etc...
PPS: Keep in mind that if someone manages to extract the certificate from your application, you are screwed either way ;-). You can imagine a store providing an individual certificate to each app and invalidating the certificates that are compromised.