There is website A, with its pool of users. There is a separate website B, which sells digital goods.
I want to allow users of website A to make a purchase from website B, without registering or visiting B.
Given that site A has an agreement with site B to pay the bill on a monthly basis, how can you authorize purchases without opening a vulnerability for malicious attackers?
The first solution which come to my mind, storing a master password to authorize single user purchase, is a security nightmare, but I can't thing anything better. Any ideas?
You can use SAML (http://en.wikipedia.org/wiki/SAML) for this purpose.
Site A will have username/password and other information to authenticate end users. After authentication, site A can send users to site B and site B will call a service exposed by site A to confirm that user is indeed sent from site A.
E.g.
user 'abc' logins on site A
user clicks on something (on site A) to buy something from site B
Site A generates some random and unique token for this action.
User is sent to Site B (usually by POST on a form that points to site B). One of the form fields would be this token
Site B calls some service on Site A to validate the token and to retrieve username for which token was generated. Service might return other things like purchase limit for this transaction.
It is VERY important that the whole communication happens over SSL. This will help mitigating Man-in-the-middle attacks.
Related
Let's say there's a website A where I have permission to manage accounts and credentials in order to give access to other users, and i want to limit users to 2 different devices at maximum(one mobile, one laptop/desktop); but I don't own A so I can't modify or even view the source code.
I was wondering if it was possible to create a website B where I store server-side the credentials of website A, and give users credentials of website B instead, verify the restrictions there, and redirect them to A already logged in.
After checking FAQs of Securekey Concierge( company which provides authentication services) I have a doubt that there is a possibility of session replay which can compromise the login security. Here is how it works
Lets say that A is the government site to which I want to log in. Instead of creating a new user name and password for site A, I select Securekey Concierge (Say it site is B). Then from site B I pick my financial instituition where i will be logged in. Lets say it is C. So After log in C I will be redirected to the site A along with a randomly generated token where I will fill the rest of the detail to complete the first time sign in process. So the next time I sign in to site C, the same random token will be sent to site A which will recognise me and won't ask the fill in the same detail I did first time.
So my question is that I am not sure if the random token flows through site B. If it does then there is a possibility that some one on site B can use that token to impersonate me.
I known single sign on e.g. Google sign in where only two sites are involved and each time the sign is completed that first site get the info from Google session which is always different for each sign in.
But in Securekey Concierge, the same token is sent by the site C each time I log in and if this token flows through the site B which is broker site then I doubt that there could be a session replay using that token.
If any body aware of Securekey Concierge, could you please elaborate it.
Thanks
My customer has an intranet portal and wants to have a button in it such that when clicking on it it would open my web site and login the user that was in the customer intranet automatically into my site.
The user, on both the intranet and my site, have the same user ID (the user ID is basically the email).
We do have IP authentication in place, so my site already knows the IP from where the intranet site is coming from, so that it authorizes it. Unauthorized IPs are redirected to kick them out.
How can my customer pass the user ID (aka the email in my case) from his Intranet to my web site, in such a way that it is secure?
Here are my concerns about being secure:
A) is the user ID is passed as a parameter to my web site (for example as part of the query string in the url or as a hidden input field in a form in a POST call), then there is the danger of anyone in that intranet altering this user ID by anyone else's user ID and entering as them. For example, if I am joe#abc.com, then joe#abc.com would be passed somehow from the intranet to the site as a parameter. I could easily make a change from joe#abc.com to dave#abc.com which would then log me in the site as dave#abc.com.
B) let's say that the user ID is then encrypted. So, now joe#abc.com becomes something like AAABBB000111. If I share this encrypted value with anyone, then this person could use the encrypted value and login as me. Of course I would have to share this encrypted value with him.
So, do you think that there is a good and elegant way to accomplish passing the user ID from the intranet to the external site in a secure way?
Query string can easily be used to pass this information over but if its secure i would not do that. You can pass it in a cookie which would be very easy again, If that isn't an option because the data is sensitive, you could look into sessionStorage to store the data temporarily between pages.
Sending it to the server sounds the best bet log them in save there session in a cookie and then redirect them.
Our web app. sends reports out to users which contain links that point to various items within our web app. (specific records). Users ordinarily have to login to our system to access it, so I am wondering what the best methods are of allowing one of these links to direct the user to the area of the system, without them having to repeatedly login.
When you create a link, you can note which user this link is for. When user clicks on the link, fetch information for the user. Guid in your url would guarantee that no other person can guess path for that users data. This will not technically authenticate a user. But will allow them to see data you need.
First of all it's bad idea to distribute user credentials even to a known email address.
You can generate a unique key for each customer and insert it in query string of included URL in the email. once user clicks on the sent URL, system discovers which user is dealing with and authenticates user. After successful authentication process it really makes sense if you disable the sent unique key.
I'm designing an online store with Wix.
They have a great graphic interface which allows non-developers like me to build a professional-looking online store.
However, since I'm a noob in online security, I have this concern - the Wix webpage doesn't support SSL within their pages. But as soons as the customer clicks check out to begin the paying process, he is redirected away from the Wix site to the merchant account page (like paypal etc). The merchant do support SSL.
I'm assuming that although the Wix webpage doesn't support SSL, there is no risk envolved for the customer since he'll be entering his credid card info etc in the merchant account page. Is this correct? If I'm not clear, here is the Wix explanation for the matter:
Is Wix eCommerce secure?
When a customer makes a purchase on a Wix eCommerce site or a site with a PayPal or the Add to Cart button, the only information added by the customer on the Wix site is the product and any product options. Once a customer clicks Checkout, the customer is redirected away from the Wix site and to your merchant account page. Any personal or payment details that the customer has to enter are therefore not entered on the Wix site but rather on the merchant account site which is secured by the merchant account. For more information about exactly how they encrypt and secure payment information, please contact the relevant merchant account.
I'm also assuming only this risk (from the customer's perspective). Are there more risks involved in the Wix website by not supporting SSL? Maybe hacking the website or something? (from the seller's perspective)
This question might be suitable for serverfault.com instead.
But as it's related to development I'll try to answer it to the best of my ability:
When the connection is not carried over SSL (or any other security measure), the traffic is interceptable and malleable. This means that you can not trust that the data you are getting is actually from the user, unaltered. Additionaly, the user cannot trust that he is in fact talking to your server directly without someone in the middle snooping or altering the data.
Seeing as the payment system is a separate system that does allow for SSL, then you have the most obvious security issue covered. It is then up to you to evaluate whether anything up to that point can be considered sensitive. (for example username and password, if the store requires a login).
A good rule of thumb is that "Anything not encrypted is potentially known by anyone. In addition it is also alterable." Say a user wants to place an order, and clicks the appropriate buttons and links to get to the payment system. Now, if a MITM attacker wants to snoop the credit card details, he can intercept the traffic and substitute the buttons and link to trick the user to his own system, made to look like yours, with the only purpose of gathering credit card details. Attacks like this are possible because the average user doesn't know or care about the danger of accepting certificates from untrusted sources, and it is hard to combat unless awareness is raised around the issue. I have seen online shops display a warning before accessing the payment system that the user needs to verify that the certificate actually stems from their server, and that the URL is still refers to their webshop.
...But i digress. To sum up: You've got the important part secure. As for the rest, there are some pitfalls, but manageable if handled properly.