HIPS AB is a financial technical service provider, to enable consumers to make online purchases. The activities of the company follow local laws, regulations and industry practice. Hips AB's principal place of business is registered at Strandgatan 1, 302 46 Halmstad (Sweden), registered in the Swedish companies register under the registration number 559114-1873.
HIPS Betalservice AB is a provider of financial services (factoring services), to enable consumers to pay after delivery. In the EU/EES, HIPS Betalservice AB is registered as a financial institution firm by Sweden's financial supervisory authority under number 559114-1873 by the Swedish Financial Supervisory Authority (www.fi.se), Box 7821, 10397 Stockholm, Sweden.
Hips AB and HIPS Betalservice AB's principal place of business is registered at Strandgatan 1, 302 46 Halmstad (Sweden), collectively called "Hips".
Hips Checkout is a technical platform of storing your Payment Credentials, but it doesn’t change anything else about your relationship with the Merchant you’re paying or your bank or credit card company. You are ultimately responsible for the purchases you make using Hips Checkout. Also, the Merchant is the one responsible for providing you the goods or services that you purchase using Hips Checkout, not Hips. Hips will use our reasonable efforts to keep your Payment Credentials secure. Hips may buy any debt from you to the Merchant (factoring), in that case you will be notified and must fulfill you payment toward Hips and not the Merchant.
HIPS has been audited by a PCI-certified auditor and is certified to PCI Service Provider Level 1. This is the most stringent level of certification available in the payments industry. To accomplish this, we make use of best-in-class security tools and practices to maintain a high level of security at HIPS. The PCI audit occurs annually.
HIPS act as a financial technical service provider, which support the provision of payment services to banks and authorized payment institutions. Some of HIPS services includes a e-commerce platform ("Checkout"), for such services HIPS act as a commercial agent authorised via an agreement to conclude the sale on behalf of the payee.
Security is one of the biggest considerations in everything we do. If you have any questions after reading this, or encounter any issues, please let us know.
All card numbers are encrypted on disk with AES-256. Decryption keys are stored on separate machines. None of HIPS’s internal servers and daemons are able to obtain plaintext card numbers; instead, they can just request that cards be sent to a service provider on a static whitelist. HIPS’s infrastructure for storing, decrypting, and transmitting card numbers runs in separate hosting infrastructure, and doesn’t share any credentials with HIPS’s primary services (API, website, etc.).
No technology is perfect, and HIPS AB believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.
Thank you for helping keep HIPS AB and our users safe!
Understanding security impact of a given report is understanding what mitigating or multiplying factors exists. Below are some categories to consider when assessing security impact.
sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.
scale of exposure -- when considering security impact of any given vulnerability, it's important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.
severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user's last name versus their bank account number have drastically different security impacts.
requires user interaction -- when an exploit scenario requires a human from Hips or a Victim to manually interact before exploit is successful.
authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.
requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how "hard" it is to brute force the value in question -- brute forcing phone numbers is much "easier" than a UUID.
existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be "mitigating" factor since it doesn't require actually having unique IPs.
physical access -- exploit scenarios requiring physical access to a device.
noticeable to victim -- exploits that are noticeable to victim. For example, changing someone's password on their account would lock them out of their account and would be immediately noticeable. account put into arrears or banned -- when an exploit then puts the Attacker's account into arrears or results in a ban.
social engineering -- when an exploit requires social engineering a person to be successful.
requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful
requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely.
We strive to be consistent with how we close reports and below are the details for each state:
spam -- a report with no useful information\ needs more info -- not enough actionable information in report to triage\ not applicable -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\ duplicate -- a vulnerability that has previously been found either internally or via Hackerone\ informative -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named hips-secret-stuff that isn't actually related to us)\ triaged -- either a valid report or a report that needs more investigation from an internal team, typically the former\ resolved -- a verified vulnerability that has been fixed
Previous bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.
We focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.
We recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact.
The general process for determining bounty:
The bounty ranges:
A reward of USD $500 may be provided for the disclosure of qualifying vulnerabilities. At our discretion, we may increase or decrease the reward amount based on the mitigating and multiplying factors.
If you report a vulnerability that does not qualify under the above criteria, we may still provide a reward of USD $100 if your report causes us to take specific action to improve HIPS's security.
Bounty payouts, if any, will be determined by Hips in its sole discretion. In no event is Hips obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by Hips in its sole discretion. For example, Hips may give you one (1) payout in-full or a partial payout when the vulnerability is first verified followed by an additional payout once the vulnerability has been fixed. You are solely responsible for any tax implications related to any bounty payouts you may receive.
High quality submissions allow our team to better understand the issue and relay the vulnerability to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.
Note: Severity shown here only indicates the maximum severity possible for reports submitted to the Asset.
Our security team rapidly investigates all reported security issues. If you believe you’ve discovered a vulnerability in HIPS’s security, please get in touch with HIPS Security Incident Response Team at email@example.com (optionally encrypted using our public PGP key). We will respond as quickly as possible to your report. We request that you not publicly disclose the issue until it has been addressed by HIPS.
We're always happy to help with code or other questions you might have! Search our site for more information or send us an email (firstname.lastname@example.org)!