how to encrypt or encode a formula filed in quickbase

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • In Progress
I need to save a password filed in quickbase table.how to encrypt or encode that filed for security
Photo of Hashmi V J

Hashmi V J

  • 160 Points 100 badge 2x thumb
  • sad

Posted 2 years ago

  • 0
  • 1
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 51,436 Points 50k badge 2x thumb
If only there was a cryptographer who also happened to be a white hatted hacker who haunts this Forum. Let's see if one shows up today..
Photo of Hashmi V J

Hashmi V J

  • 160 Points 100 badge 2x thumb
I just want to hide password in a field in order to hide it from third party viewer.Just like converting to some coded form(encrypt form)
Photo of Harrison Hersch2

Harrison Hersch2

  • 400 Points 250 badge 2x thumb
This is a great question. The decision point here comes down to obfuscate or secure.

Option #1 - Obfuscating can be done in multiple ways. You could simply hide the field on the View form, have a form rule that blanks the field out so basically the password is "re-settable" but never "readable". You could also have a formula field that shows the password field is filled in with asterisks but not reveal the actual password.
Option #2 - True security needs to be handled outside of QuickBase, passing hashed or encrypted values into a QuickBase field. Ideally, this would be done server-side since operations occurring inside of JavaScript can be reverse-engineered client-side. So a common approach I've taken is having a button on the form that says "set password" which launches a small UI. The user keys in the credentials into a secure location server-side, the values are encrypted and sent back into QuickBase. If the passwords do not need to be reversed (i.e., never readable by human or code), a one-way hash is used (such as authentication with a web site that talks to QuickBase). Something like Azure Key Vault is also an option.

Hope this helps.
Photo of QuickBasePros_IDS

QuickBasePros_IDS, Champion

  • 2,266 Points 2k badge 2x thumb
You can hide field content at the Role Level and prevent users from seeing a field and its contents.  Could you not invoke this?
Photo of Harrison Hersch2

Harrison Hersch2

  • 400 Points 250 badge 2x thumb
It depends on the use case if this protection is sufficient. In most cases, passwords shouldn't be human readable.
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 26,532 Points 20k badge 2x thumb
I assume you want to store the password in QuickBase for the purpose of later retrieving it out of QuickBase and restoring someone's credentials to some third party system (someone forgot their password or left the company or you want to assume control of their account and change the password).  In general passwords should never be stored in plaintext and passwords should never be encrypted (ie capable of being decrypted). Passwords should be hashed, salted and have a high work factor associated with testing the password.

That said, I suspect your passwords may be for some low value system such as a printer password or a closet door PIN code. In that case I would use roles to protect the password and only give an administrator access. 
Photo of Harrison Hersch2

Harrison Hersch2

  • 400 Points 250 badge 2x thumb
Totally agree with Dan here about the password security. @Dan - there may be a case though where the password needs to be decrypted such as a software solution retrieving service account credentials at runtime (stored in memory, not disk ever).
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 26,532 Points 20k badge 2x thumb
I teach cryptology occasionally - passwords should never be encrypted. When you log into a service the password is hashed and the hashed password is compared to the saved hashed password held by the server in a database. If the two hashed passwords are the same access is granted. Hashing is not the same as encryption. Encryption can be reversed while hashing is irreversable.

TIP: If you are using any service where you can retrieve your password rather than set up a new password the service is INSECURE.
Photo of Harrison Hersch2

Harrison Hersch2

  • 400 Points 250 badge 2x thumb
Yes, Dan. Totally agree with all of this. If you click "forgot password" on a forum/website/whatever, and they e-mail you your password, it means they are able to reverse it which is completely insecure.

What I'm referring to Dan, is let's say you have an integration hosted in .NET/PHP/Ruby that talks to QuickBase to read/write data. Many people have a practice of just storing those credentials in a config file plain-text readable by anyone with that access. How are you handling this? If you do one-way hash, how is your code ever going to pass a username/password or usertoken or userticket to QuickBase to perform the API calls?
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 26,532 Points 20k badge 2x thumb
Yeah we are on the same page although storing credentials in a config file isn't the best practice (I do it all the time for low value services).

I suspect the OP just wants to the illusion of security for some low value asset so he can tell his boss they are totally locked down.
Photo of Harrison Hersch2

Harrison Hersch2

  • 400 Points 250 badge 2x thumb
Yes absolutely, was just commenting/clarifying/inquiring as to the difference in needing to store a password that is one-way vs needing one to be reversible (i.e., encrypted and decrypted at run-time via custom utility or something like Azure Key Vault).