Fraud Prevention Headers Support

[mtd-api-team]

Questions about Fraud Prevention Headers that require HMRC support should be referred directly to SDSTeam@hmrc.gov.uk. They will not be answered by a member of HMRC on GitHub.

As the MTD API team cannot directly answer any Fraud Prevention questions, this repository will not be monitored for issues related to Fraud Prevention, and any new Issues raised around these Headers will be directed to this Issue and closed.

Please use this Issue instead for any discussion related to Fraud Prevention that does not require immediate HMRC support.

[Roger1952]

If fraud prevention headers are not part of the API then what are they? Anyway, emailing questions to the SDSTeam is a waste of time unless they start responding in a timely manner.

[KenRandall]

I still actually fail to see what most of these ill conceived and poorly implemented headers have to do with fraud prevention!

[Yottskry]

"They will not be answered by a member of HMRC on GitHub."

Yeah, the trouble is they're not being answered by the SDS team via email either.

I'm so exasperated with HMRC right now. Your left hand doesn't know what your right hand is doing, and everyone just passes the buck to everyone else. If you were anyone but a government department no one would do business with you. You're just so amateur in your attitude.

[Roger1952]

It would be interesting if HMRC could use this forum to put forward a reasoned argument as to why we are all wrong and why their API support really is fit for purpose. Unless of course we are right and it isn't.

[LukeHirst]

If we cannot get answers to our questions from the issues posted here than can we get a definite answer for when the Fraud Prevention Headers will be available in the sandbox for the MTD-API?

If developers had something tenable to test against rather than having to get the fraud prevention headers manually evaluated in production, than I believe the amount of queries you will receive on GitHub about these headers will greatly diminish.

[Roger1952]

I submitted headers by email for comment on 19th March and apart from a response saying "we'll take a look and get back to you" I've heard nothing.

This is absolutely ridiculous.

If all developers just withdrew their software until HMRC got their act together on support they wouldn't be able to collect any VAT. That might get their attention.

[KenRandall]

I got a response today.

[adamdavi3s]

I got a response yesterday, from the 6th of March

[ghost]

How are you getting the Scaling Factor for Gov-Client-Screens ?

I'm struggling to understand exactly what HMRC mean by the scaling factor and how I can reliably get this in a Win32 program (using Windows API calls or the Registry etc). It seems there's just too many variables to take into account - manifest DPI awareness, monitor settings, screen setting etc etc.

Any help/suggestions much appreciated. I've email the SDSTeam but with no response so far.

[Roger1952]

1 is a very nice scaling factor.

[Roger1952]

HMRC have now decided that it's too much effort to review the Fraud Headers

"We are now going to move away from manual reviews and focus our efforts on exploring and delivering more efficient methods to help you. We are asking that you do not send further requests for a manual review. However, if you have a specific question or concern around the fraud prevention headers you are providing, please let us know and we will try to provide you with support as quickly as possible"

So the API folks can't and the SDSteam folks won't help. Wonderful.

[KenRandall]

I actually received an email from them the other day saying mine are fine. Took me many goes though!

[Roger1952]

They are going to have to sort this out some time. But, why put off till tomorrow what you can put off till the day after.

[ddaddy]

I had a response saying I need to percent encode the IP’s, however their is different standards of what characters are allowed. Would be handy if they provided a spec on which characters need percent encoding.

[EwanReid]

Got an email from the SDS team stating that I am not submitting any fraud headers at all. Despite the fact they are sent the exact same way as the authentication headers. And my logs prove they are being sent.

The only one that was not fully implemented and wasn't being sent up was the Device-id.

I apparently have a month to fix this, before they check their logs again. I asked for clarification as to if I am sending no fraud headers what so ever, but of course it has only been two weeks, so I have heard nothing back.

It really is quite bizarre that the SDS team send these emails, when there is still no way to test that these headers are being sent, let alone test if they are valid.

Update. It appears as if there SDS team made a mistake and identified my application as not sending the fraud headers when in fact it was.

This just re-enforces the need for some way of testing these headers, and this needs to happen soon. Thankfully we hadn't assigned a lot resources to look into the issue as of yet, but if we had spent time trying to troubleshoot, only to find out nothing was wrong, I would be a bit peeved off.

[GJustas]

Hello,

As you may know by now that HMRC is now having new API in which validates fraud prevention headers. I implemented fraud prevention headers in our software in march and tried now to validate them and got few errors:

1. We don't supply scaling factor. I agree to that but we develop our software using C# and it's kinda „hacky" to get scaling factors of multiple screens and if you get them it's not guaranteed to be correct. So what do I do in this situation ? Just „hardcode" value - 1?
2. There are multiple errors in Gov-Client-User-Agent fraud prevention header, it says that „At least one value for 'Device Manufacturer' is missing." and „At least one value for 'Device Model' is missing.". But in your documentation you specify that „If you cannot discover any information due to operating system constraints, leave the appropriate field blank". So I leave appropriate fields blank and you still show that my fraud prevention header is bad. For example these examples is showing like errors: Windows/ (/) Windows/5.1.2600 (/).
3. Blank fraud prevention headers shows like warnings in validation response.

Also what do HMRC have in mind when connection method is „DESKTOP_APP_VIA_SERVER" ? For example if I connected to server via RDP and our application is accessed through RDP so that means that my connection is DESKTOP_APP_VIA_SERVER ? Because if I launch application in remote desktop connection it collects server information and not machine information from which remote desktop connection is launched.

[mtd-api-team]

Hi @GJustas,

Questions about Fraud Prevention Headers that require HMRC support should be referred directly to SDSTeam@hmrc.gov.uk. They will not be answered by a member of HMRC on GitHub.

As the MTD API team cannot directly answer any Fraud Prevention questions, this repository will not be monitored for issues related to Fraud Prevention, and any new Issues raised around these Headers will be directed to this Issue and closed.

Please use this Issue instead for any discussion related to Fraud Prevention that does not require immediate HMRC support.

Kind regards, mtd-api team

[ddaddy]

@GJustas Have you had any communications with SDSTeam about your headers? I had mine checked by an SDSTeam member and after making a few changes they approved them. Even though I cannot supply the MAC address, so I get an error with the new validation API. I emailed them this morning to suggest the MAC address should be optional, but I guess this change won't happen and missing things out will just be approved on a case by case basis.

[lewisrenfrew]

I've been using the new sandbox testing functionality to test out my headers and am confused by the fact that several headers that the API docs say are possible to omit, e.g.

'If only a single factor (for example, username and password) is being used, submit the header with an empty value or omit it entirely.'

still yield errors as opposed to warnings in the test response. Am I right in assuming errors MUST be addressed prior to production whereas warnings are just FYI?

We need to leave some of these blank due to our environment but these errors aren't encouraging...

[dawnvf]

I have been submitting fraud headers in production for some time but have had no information regarding whether or not they were correct. I have just started using the Test Fraud Headers API and have made a few tweaks so that they appear to be correct for DESKTOP_APP_DIRECT connection.

I am now working on the additional headers for DESKTOP_APP_VIA_SERVER. These include Gov-Vendor-Forwarded and Gov-Vendor-Public-IP, neither of which are available to me as the forwarding occurs within a private network. If I omit either header or provide an empty header this is reported as an error despite the documentation suggesting that these headers may be empty.

Is it really an error or is the API reporting an error where it should be reporting a warning?

[craigfrancis]

Just to note my concern (again) "Gov-Client-Multi-Factor", with TOTP, while the documentation says you should not use the original secret... you shouldn't use the time based codes either (salting can help, but the salt must be kept a secret at all times).

For details, a TOTP value is typically a 6 digit number that changes every 30 seconds. Even if that's hashed, it's trivial to get the hash back to original 6 digit value (takes about 0.4 seconds on a single-core general-purpose CPU to try all 6 digit combinations). Also, TOTP is nearly always based on the now deprecated SHA1 algorithm (still the case if you support Google Authenticator). Technically SHA1 is fine to generate the 6 digit numbers, so long as those values are not recorded anywhere (e.g. providing all of them to a 3rd party, along with the timestamp and AccountID the codes were valid for).

[euyfcheD]

Re: Gov-Vendor-Forwarded for DESKTOP_APP_VIA_SERVER application

Afternoon, I have created the following string of values (data has been changed to fake data for privacy reasons) which are being sent to the Fraud prevention testing api Gov-Vendor-Forwarded: by=123.45.67.89&for=456.789.01.234,by=18.165.61.72&for=123.45.67.89 where: 456.789.01.234 is the ip address of the users pc 123.45.67.89 is the ip address of our web server that processes the request and sends it to the hmrc endpoint 18.165.61.72 is the hmrc sandbox server

any suggestion why i am getting the following error when i sned the data to the fraud prevention endpoint? {"specVersion":"3.2","code":"INVALID_HEADERS","message":"At least 1 header is invalid","errors": [{"code":"INVALID_HEADER","message":"At least 1 value for 'by' is missing","headers":["gov-vendor-forwarded"]} ,{"code":"INVALID_HEADER","message":"At least 1 value for 'for' is missing","headers":["gov-vendor-forwarded"]} ,{"code":"INVALID_HEADER","message":"Value is not an IP address","headers":["gov-vendor-forwarded"]} ,{"code":"INVALID_HEADER","message":"Value is not a public IP address","headers":["gov-vendor-forwarded"]},

tia

[mPisano]

It took me awhile to get the headers encoded accurately in c# for DESKTOP_APP_DIRECT but has been running flawlessly for 5 years.

Project was a plugin for Acumatica, my fork is now a stand alone lib with a test project.

My version is @ https://github.com/mPisano/MTDCompliance

HTH Mike