Password policy for Intuit Developer Services

The purpose of this policy is to ensure the creation of strong passwords, the protection of those passwords, and the frequency of change for passwords for applications that integrate with Intuit Services. This policy sets forth minimum requirements. You are encouraged to implement a stronger password policy.

This policy applies to the Intuit Developer Group’s customer facing platforms.

Effective Passwords: Passwords should be difficult to guess, yet easy to remember. The password policy includes the required alphabet size. The required credential creation policy depends on the service being integrated. [See below]

Financial Data API: The Financial Data API provides developers access to end-user financial account and transactional information from financial institutions.

QuickBooks Accounting API:The QuickBooks API is a set of coding components and web services you can use to leverage and extend QuickBooks Online features.

QuickBooks Desktop QBXML SDK:The QuickBooks Software Development Kit (SDK) allows you to develop desktop software solutions that integrate with QuickBooks for Windows.

Payments API:The Payments API is a service that processes credit card payments.

A password system shall enforce a minimum length of six characters. The password system must support passwords up to at least 128 characters.

A password shall consist of the following:

• Letters [required 1]:a, b, c, d, e, f, g, … x, y, z, A, B, C, D, E, F, G, … X, Y, Z – AND
• Numbers [optional 1]: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 – OR
• Symbols [optional 1]:~, !, @, #, $, %, ^, &, *, (, ), -, _, =, +, [, {, ], }, \, |. ;, :, ‘, “, ,, ., <, >, /, ?
• Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries).
• Verify password is not the same as, or a trivial variation of the username.
  • If Account ID is ‘fred’, then password cannot be ‘fred’ ‘fred1’ 1fred’, ‘fr3d’, etc.
  • Password check should look for Account ID string in the password
• Password system must support mixed case passwords (Password1 should yield a different result than password1)
• Passwords will expire no later than one hundred twenty (120) consecutive days after issuance.
• Products must accommodate Account ID lockout after 10 consecutive failed password login attempts.
  • The failed count (if currently under 10) should reset after a successful login
  • If the 10th consecutive failed attempt is reached, the Account must be locked out for a minimum of 24 hours
• After a password expires, the user must select a new password
  • The password system must remember the previous 5 passwords for each user
  • The user may not select a new password that was one of the previous 5 passwords for that user
  • The user may not change their password more than 1 time per hour

A password system shall enforce a minimum length of six characters. The password system must support passwords up to at least 128 characters

A password shall consist of the following:

• Letters [required]:a, b, c, d, e, f, g, … x, y, z, A, B, C, D, E, F, G, … X, Y, Z
• Numbers [optional]: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9
• Symbols [optional]:~, !, @, #, $, %, ^, &, *, (, ), -, _, =, +, [, {, ], }, \, |. ;, :, ‘, “, ,, ., <, >, /, ?

The following is for developers using any of our services:

Passwords represent a “something the user knows” factor. If the user forgets their password, an alternate “something the user knows” challenge should be presented to the user, on request.

• Challenge questions, when implemented correctly, can be used as an alternate knowledge challenge.
• There are also several image based authentication systems that would make a suitable alternate knowledge challenge
• Email is neither “something the user knows” nor “something the user has”, and is not considered an authentication factor in an authentication flow. However, when coupled with an alternate knowledge challenge, email can introduce a protective additional step. When a user selects the link for ‘forgotten password’, consider emailing the alternate challenge flow URL to the user’s registered email address.

The following is for developers using our Financial Data or Payments APIs:

• Account IDs and Passwords must be protected when transmitted with encryption
• Do not operate a non-encrypted version of the authentication page
• The SSL Server certificate configuration in use on the server must maintain a letter grade of A or B, as defined by SSL Labs
• See SSL server rating guide for more details about the grading
• See SSL server test to perform a third party test of your site, indicating the grade
• Restrict use of “Remember Password” features.
  • For example, instruct web browsers to disable password auto-complete for the password field

The following is for developers using our Financial Data or Payments APIs:

• End-User Account IDs may be stored in plain text
• End-User passwords must not be stored in plain text
• Passwords must be one-way hashed with bcrypt, scrypt, or PBKDF2
  • Must use a unique salt, per password
  • If using PBKDF2, recommended minimum of 10,000 iterations

Application must not store End-user credentials that may be used to access end-user data from another source (e.g., the end-user’s financial institution), unless specific approval has been given by Intuit. For developers who receive specific Intuit approval to store end-user credentials that may be used to access end-user data from another data source (e.g., the end user’s financial institution), storage must comply with the following:

• End-User Account ID must *not* be stored in plain text. If stored, AES encryption with 256 bit keys (or better) must be used to protect the contents of the Account ID field.
• End-User passwords must not be stored in plain text
• Passwords must be one-way hashed with bcrypt, scrypt or PBKDF2
  • Must use a unique salt, per password
  • If using PBKDF2, recommended minimum of 10,000 iterations