I'd like to propose addressing the current allowable password length (20 characters).
Our single sign on environment allows up to 48 characters and the current limit should support NIST guidelines (800-63B): Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. [...] Users should be encouraged to make their passwords as lengthy as they want, within reason.Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes.Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.
Monthly Subscription with a Report Link
Hello All, Is there a way to send a Monthly Subscription with a link to a report rather than including the report data in the body of the email or as a PDF or CSV attachment? Much of our report data includes personal information that we want to be sent via secure email. Providing a link would at least require a person potentially intercepting an email to be set up as a user or enter an accurate password to access the information. I realize a Notification could be set up; however we wouldn?t want an email every time a change occurs ? only weekly or monthly, and it would be helpful to give easy access to the report [via link] to view all associated records. Thanks in advance for your time and assistance!
Security Concern
Hi All, One of our client has raised the security concerns while accessing QuickBase Using API's. Following is the sequence of the calls made to access the QuickBase from the external system. First call for the authentication to get ticket: POST //db/main HTTP/1.1 Host: https://target_domain Content-Type: application/xml QUICKBASE-ACTION: API_Authenticate Cache-Control: no-cache Postman-Token: a66300eb-891b-2764-d7ad-f4a6e0b45452 <qdbapi> <username>USER NAME</username> <password>PASSWORD</password> <hours>24</hours> </qdbapi> O/P: Ticket After first call of authentication, when subsequent calls are made to the QuickBase without passing the Ticket , still we get the desired output and this pose the serious security concern, as anyone can do the random calls to the QuickBase and get Data till the ticket is valid. Second call without ticket: GET /db/bm272rhqa?a=API_DoQuery&query={'3'.EX.'42'}&clist=3 HTTP/1.1 Host: https://target_domain Cache-Control: no-cache Postman-Token: e71e843e-1a90-54f8-cfac-80a6bfe8d89b O/P : Desired XML Data As a immediate fix we have asked the client to use "API_SignOut" API to invalidate the ticket, but still if ticket has duration of , say of 4 hours and during that four hours is it possible to make sure that no API calls can be made to QuickBase without passing valid ticket in each API Calls. ThanksAccess Record data from an html page via API call
I have had a hard time getting accustomed to working with API calls from outside of Quick Base and since I have limited experience with XML. Finally after struggling quite a bit I have come up with a (seemingly) decent method for getting/accessing record data from an API call in an HTML page. I will post the code below and please provide any feedback for this method, I am still early using Quick base API calls. This method uses the option to return the record data as a 2-dimensional array that can be accessed with "qdb_data " where the "x" is the index selector. You can easily check the number of returned records by looking at "qdb_data.length" <head> <script lang="javascript" src="yourdomain/db/ yourtable?a=API_GenResultsTable&query={'field id'.operator.matchvalue}&jsa=1&apptoken=[yourtoken]"> </script> <script> function displayData(){ alert(qdb_data ); }</script> </head> Curious about the security of having the API info and app token within the client-side code. Obviously a QB code page is fairly secure compared to a remote code page but still curious about it. Thanks everyone.
Does QuickBase currently support publicly available two-factor authentication?
Hi, Does QuickBase currently support Google Authenticator or similar publicly available two-factor authentication? If so, how do I turn that on? If not, why not and when will this critical security functionality be available?
