I tried contacting Amazon support for this, but they have not replied since last week (unfortunately this is typical to not hear back for days, up to weeks). We currently do FTP for our EDI communication, but that is being discontinued at the end of this month, and we are trying to implement AS2, but we have more than one company internally, so as of now, we have 2 logins with Amazon, and each one has their own FTP in which we pull and push EDI data back and forth.
Each trading partner with AS2 requires an identifier certificate (I believe is what it is called), and it costs a decent bit of money for them, but I need to know if we need only one, or two of them considering that we have two FTP's (VendorCentral accounts) currently, but it is the same trading partner. If anyone knows anything about AS2 in general and could shed some light on this, I would be extremely appreciative!
Thanks!
Dan
Ok, I realize this is an old post but since I've recently researched it for an article this may still help anyone else looking for this info.
You can think of AS2 like an email where the url is the domain name and the ID is the part before the #.
AS2 requires:
a URL
a unique AS2 ID for that URL
The client certificate is used for security reasons but doesn't have to be unique per connection.
So you can stick to a single certificate for all your Amazon vendor central connections.
That being said, Amazon expects one connection per document type. This means you can't have purchase orders incoming through two different AS2 connections at the same time for example. So if your "sub-companies" are dealing with the same documents they will have to continue working with separate vendor central accounts.
Related
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
We have an application that includes a voting component.
To try and minimise voter fraud we allow N number of votes from the same IP address within a specific period. If this limit is hit we ignore the IP address for a while.
The issue with this approach is if a group of people from a school or similar vote they quickly hit the number. Their voting can also occur very quickly (e.g. a user in the class asks his classmates to vote which causes a large number in a short period).
We can look to set a cookie on the user's computer to help determine if they are sharing accounts or check the user agent string and use that too.
Apart from tracking by IP, what other strategies do people use to determine if a user is a legitimate or a shared account when the actual IP is shared?
If your goal is to prevent cheating in on-line voting, the answer is: you can't, unless you use something like SSL client certificates (cumbersome).
Some techniques to make it harder would be using some kind of one time token sent trough e-mail or SMS. Every smart kid knows how to cheat control cookies using privacy mode of modern web browsers.
I want to create a portal website for log-in, news and user management. And another web site for a web app that the portal redirects to after login.
One of my goals is to be able to host the portal and web-app on different servers. The portal would transmit the user's id to the web-app, once the user had successfully logged in and been redirected to the web app. But I don't want people to be able to just bypass the login, or access other users accounts, by transmitting user ids straight to the web app.
My first thought is to transmit the user id encrypted as a post variable or query string value. Using some kind of public/private key scenario, and adding a DateTime stamp to key to make it vary everytime.
But I haven't done this kind of thing before, so I'm wondering if there aren't better ways to do this.
(I could potentially communicate via database, by having the portal store the user id with a key in a database and passing that key to the web app which uses it to get the user id from that database. But that seems crazy.)
Can anyone give a way to do this or advice? Or is this a bad idea all-together?
Thanks for your time.
Basically, you are asking for a single-sign-on solution. What you describe sounds a lot like SAML, although SAML is a bit more advanced ;-)
It depends on how secure you want this entire thing to be. Generating an encrypted token with embedded timestamp still leaves you open to spoofing - if somebody steals the token (i.e. through a network sniffing) he will be able to submit his own request with the stolen token. Depending on the time to live you will give your token this time can be limited, but a determined hacker will be able to do this. Besides you cannot make time to live to small - you will be rejecting valid requests.
Another approach is to generate "use once" tokens. This is 'bullet proof' in terms of spoofing, but it requires coordination among all the servers within the server farm servicing your app, so that if one of them processed the token the other ones would reject it.
To make it really secure for the failover scenarios, etc. it would require some additional steps, so it all boils down to how secure you need it to be and how much you want to invest in building it up
I suggest looking at SAML
PGP would work but it might get slow on a high-traffic site
One thing I've done in the past is used a shared secret method. Some token that only myself and the other website operator knows concatenated to something identifying the user (like their user name), then hash that with a checksum algorithm such as SHA256 (you can use MD5 or SHA1 which usually are more available but they are much easier to break)
The other end should do the same thing as above. Take the passed identifying information and checksum it. Compare that to the passed checksum, if they match the login is valid.
For added security you could also concat the date or some other rotating key. Helps to run SSL on both sides as well.
In general, the answer resides somewhere in SHA256 / MD5 / SHA1 plus shared secret based on human actually has to think. If there is money somewhere, we may assume there are no limits to what some persons will do - I ran with [ a person ] in High School for a few months to observe what those ilks will do in practice. After a few months, I learned not to be running with those kind. Tediously avoiding work, suddenly at 4 AM on Saturday Morning the level of effort and analytical functioning could only be described as "Expertise" ( note capitalization ) There has to be a solution else sites like Google and this one would not stand the chance of a dandelion in lightning bolt.
There is a study in the mathematical works of cryptography whereby an institution ( with reputable goals ) can issue information - digital cash - that can exist on the open wire but does not reveal any information. Who would break them? My experience with [ person ]
shows that it is a study in socialization, depends on who you want to run with. What's the defense against sniffers if the code is already available more easily just using a browser?
<form type="hidden" value="myreallysecretid">
vis a vis
<form type="hidden" value="weoi938389wiwdfu0789we394">
So which one is valuable against attack? Neither, if someone wants to snag some Snake Oil from you, maybe you get the 2:59 am phone call that begins: "I'm an investor, we sunk thousands into your website. I just got a call from our security pro ....." all you can do to prepare for that moment is use established, known tools like SHA - of which the 256 variety is the acknowledged "next thing" - and have trace controls such that the security pro can put in on insurance and bonding.
Let alone trying to find one who knows how those tools work, their first line of defense is not talking to you ... then they have their own literature - they will want you to use their tools.
Then you don't get to code anything.
Where I work we have an ecommerce system on an intranet set up to process customer's credit cards. Currently when we charge a customer's credit card using Authorize.net we are not sending the credit card info to Authorize.net over a secure connection. Instead it goes over regular http. I'd like to get other opinions of how serious/negligent this is. Thanks.
EDIT: It looks like I'm wrong. I snooped around in the code and it looks like it's processing the credit card at https://secure.authorize.net. However, the web page where the credit card is entered is not secure. This is a different situation than I originally described. Sorry about that.
This seems very negligent. There have been too many leaks of credit card information to allow this sort of behavior.
Even if the processing was handled internal to your intranet, and not being sent up to a 3rd party, I would recommend using secured connections. You don't want this to be accessible by anybody, even internal, non-authorized employees.
I'm confused. How are you sending plain HTTP requests to Authorize.net? Their transaction endpoints don't have HTTP versions - they'd be criminally negligent to permit that.
Now that you've edited, things are a bit clearer. Yes, it's still a security risk to have the intranet page be HTTP instead of HTTPS, but far less than what your question originally indicated (unencrypted transit of the public Internet).
As it's internal, you don't need a paid SSL certificate (if cost is the reason for avoiding HTTPS - I can't think of any other good reasons) - you should be able to use a self-signed one.
It's very important and what you do can cause some serious problems.
Also it's against PCI standards and every company who process credit card information has to follow PCI standards, therefore you might go into some legal trouble to do so.
It's an absolute, unmitigated disaster. You should immediately (and I mean immediately) use at least transport level security (SSL/TLS) and if Authorize.net can set up for it, message level security as well.
I would recommend reading the OWASP guide:
http://www.owasp.org/index.php/Category:OWASP_Guide_Project (Free download)
Page 53 and onwards .. Got some great information.
I would say, what you're doing is terrible negligent and needs to be sorted ASAP ..
Will I have to pay again? I have about 9 months left before renewal but my current provider doesn't offer many options / control panels.
Update: thanks for everyone's help - I've finally completed this now.
I had to:
Ask my old registrar to "Unlock" the domain
Ask my old registrar to set the admin email address of the domain to my email
Ask my old registrar for the "authcode"
For the rest I just followed GoDaddy's instructions
What a pain in the a**
This is how it works
Lets say you have 9 more months for your current domain to expire
you transfer the domain to GoDaddy (or to any other decent Registrar)
you will be charged the price (little more or equal) to the price of booking a new domain
BUT, you will have the domain for 9 months + one year (or the no. of years you paid godaddy for)
So, you choose to transfer the domain and pay USD9.99 (for a year), you will have the domains for 1 year + 9 months
I did this when I had to switch hosts from awful, unreliable Fuitadnet. They managed the domain for me so I emailed them that I wanted to transfer my domain. (I transferred to GoDaddy.)
I don't remember all of the details, but I seem to recall it was a multiple-handshake process. First, they had to get my current registrar to release the domain; this involved having an email sent to me so I could confirm I actually wanted to release the domain. Then, I got a confirmation code that I sent to the new registrar, who did something or the other and came back with a new confirmation code. Once I entered the final confirmation code, the domain belonged to the new registrar. It took a few days and for some reason my first set of codes didn't work, but I found GoDaddy was pretty good at explaining what was going on.
I did have to pay a transfer fee, but the registration retained its length. I opted to renew it because there was a discount at the time.
If you contact your current host/registrar and they should be able to help you out; this was one of the few times I actually got good service out of fuitadnet.
You must have the domain unlocked with your current registrar and make sure that your contact information is up to date.
You can then have the new registrar submit a transfer request. This will result in you being sent a notification (assuming your contact information is accurate).
You will have to follow the directions in that transfer request email.
The domain may take up to a few days to fully transfer to the new registrar.
When you transfer a domain, you are effectively extending the registration for another year so you will be charged the standard transfer/registration fee.
If you have any questions, you can always contact the company you would like to become the new registrar. I am sure they would be able to walk you through their process exactly.
Just so you know, GoDaddy as a company has a somewhat dubious reputation. I personally have never had any problems with them but I have only a few low-profile sites and have never done anything even remotely complicated with the DNS.
You probably will have to pay. If you check with your current registrar and with your target registar and see what needs to be done with them and what the costs are.
It is diferent for every registar, even though the actual process is the same.
they charge you to transfer (like 6.99?), but godaddy will then renew it for a year. You usually need to contact your current hosting and have them release it for transfer, then follow godaddy's procedure for transferring a new domain in.
You may need to pay, but when I switched from Register.com to goDaddy.com I paid a very small amount to transfer (like $10) and also renewed the domain for another 2 years. (This turned out to be much cheaper than renewing with Register.com)
Yeah!! I was charged by my new registrar when I moved. Also remember you should have the secret key (transfer code) before you start your transfer process.
Depends on the host also. If you go with a company like BlueHost, for example, they'll give you free domain transfers from the losing registrar. I think, in fact, they may give you free transfers. They will and ask if you want to renew your domain with them which will cost you, though.
There is a domain transfer procedure. It's kind of complex, since it's intended to keep people from stealing domains by transferring them to another registrar (like happened to sex.com back in the 90's). GoDaddy does a good job of talking you through it (I've transferred a domain to them in the past). Of course, you're going to have to pay them to register the domain for you (though they occasionally offer discounts on domain transfers).