What encryption methods do you use to protect data?

Hello :grinning:

When a user signs up or logs in, I use firebase authentication and I use firebase realtime database for saving their memo data.

  1. When users sign up and log in
  2. When users save their data to the Firebase

Do we need to use data encryption methods in both of these cases? If we do, what method do you use?

I found some extensions but I want to get more information from you. I am still studying about encryption. (AES, salt ...) I want to publish this app on playstore so I should find the safest way to protect user's data.

1 Like

More than "Encryption methods" i use "técnics" to mantain mí data safe.

The encryption methods it's only a tiny part in the security of data.

Could you provide a more detailed explanation please? :thinking:

1 Like

When it comes to security; techniques refer to the methods or approaches employed to safeguard information or systems. Revealing details about your security system, even indirectly, can pose a risk.

For example, stating "I open my door with an NFC key" discloses the presence of an *NFC reader*, potentially suggesting a point of vulnerability. Similarly, mentioning "entering your house through a window using a lever" reveals a technique for unauthorized access.

Therefore, it's crucial to avoid disclosing specific details about security measures to prevent potential risks. Instead, focusing on broader security principles and best practices can help maintain a higher level of confidentiality and protection for your systems.

Absolutely, being aware of common techniques used in hacking and cracking is crucial for enhancing security. Understanding potential vulnerabilities and attack vectors allows you to fortify your defenses. It's like staying one step ahead by anticipating the strategies that malicious actors might employ.

Silly example of POST method
  • I must send data from a form (key value dictionary) in Json format to my backend.
    The most common practice is to grab each header and value and send it raw in a POST method.
    If someone intercepts the Json, they will be able to read the data sent (since many times it is not necessary to modify the information).
    In that intercepted Json, silly information can go (such as; no information is silly) as well as your GPS coordinates and DNA records.
    Which you can use to send a swarm of collaborative drones, full of nitroglycerin (homemade and gluten free) directly to crash into you.
  • "Conventions" are always used to send information, such as; user_name, password, email. So all the attacks are directed at those conventional labels (attackers are smarter than teachers).
    So... what happens if you change those labels to meaningless phrases like; email to xcvdfand my_email@my_domain.com to as909f0a9dd8a9sd90a0sdfhas676s5a5 using an encryption algorithm (as you please).
    look (an read) the Json now; xcvdf : as909f0a9dd8a9sd90a0sdfhas676s5a5 and tell me what you see.
    ¿the header: is it a username, password, domain, age, pseudonym?
    the value: is it an email, domain, account, etc? is it encrypted? in what algorithm? What if it is not encrypted and is 100% true?

No system is infallible, but many times it is about gaining security through the time and interactions that the attacker(s) spend intercepting your communications and systems (to trace them).

  • Both in that: on the server side, it is important that there are functions that filter them every time a POST is received, such as: every time the xcvdf header is received, the value is saved in "GPS" and in "DNA". And Any other header to this table or collection should be rejected
  • Regardless of the type of application, it is always good to save the data encrypted and only decrypt it on the client side (not before being sent). only by those users who must see the information or have access to it (creator or administrator user).
Silly example of GET method
  • Continuing with the previous example: every time a GET request is made, it is usually set; user_name from table or collection.

and the GET is a dangerous method if they have already deciphered the schema of your DB (precisely, using very common names in the tables or collections)

  • Instead of using a GET, you can choose to use a POST method, to bring information through a function on the server side.
  • Example: every time the POST is received with the header jdsfjl with the argument: pipiricucu, bring me the last 10 records of the table or collection orders where the products exceed $1000.
  • Example: every time the POST is received with the header jdsfjl with the argument: pipiricucu; decrypt pipiricucu with (algorithm you use), and look for the decrypted value in the table or collection customers and orders, bringing the last 100 records from the email column where the decrypted value is equal to that of the row.
  • Example: every time the POST is received with the header jdsfjl with the argument: pipiricucu; creates a table or collection with the name TTD [Target To Destroy] where the value pipiricucu matches the value in the column DNA, bringing them all together medical records, purchases, family, pets, friends and close acquaintances. and send them in an encrypted Jsonb to the fleet of killer drones that are closest to the target.

Using server-side functions and avoiding GET methods, you avoid (to) SQL injection and decryption of the DB schema, and it is also good to disable or filter the GET method (with a function) so that not just anyone can use it.

  • Good security practices (general and basic) are extremely well known by attackers, because they are also super hyper mega ultra used by coders and companies that do not hire programmers (because they are very expensive :thinking:). But there is nothing more expensive than a data security failure.

Thanks to the fact that today there are BaaS such as Firebase, Aws and Supabase (among many others), security in terms of hardware and engineering is no longer so expensive for mere mortals like us.

But even so, security on our part must be essential, following the principle of zero trust (Google and Amazon engineers will thank you)

Even using limited and basic platforms such as NoCode, the principle of zero trust must be used, with technique and knowledge, relying on the tools that are available.

Silly example of LOCAL STORE DATA method
  • It is always required to save data locally in some type of file (Json, JS, csv, TinyDb, etc) and 'always' with sensitive information (no data is silly).

Then, you can encrypt what you are going to save; my_data to kjfiwikfkskkaaw11e5w, encrypt the file from my_csv to usduiasalkkfqla.csv, then you can proceed to remove, add or change the extension, from; usduiasalkkfqla or usduiasalkkfqla.sxd
That way, within the code, you can do whatever needs to be done each time you need to save or read data.

It doesn't matter if the original file is csv and you change the extension to Jsonb (after encrypting it), because as I said, on the client side you are limited in a certain way, but you can still do a lot, such as; Make the attacker waste as much time as possible trying to decipher the undecipherable (the programmer), until he loses patience and abandons the target.

And that's what I mean by techniques and strategies.

Maybe @Taifun @Silver @vknow360 @Anke :sunglasses:

They can contribute more to the cause, since they know more about Java and how it is the core of app inventor, I am very new to the platform, I don't even know how to use RUSH for my Supabase extension (without making my PC commit suicide) :smiling_face_with_tear:

Greetings from Argentina :argentina: to the world.

  • If found it useful, here is your like.
  • I wish you weren't Argentine.
  • ChatGPT will take your job.
0 voters
1 Like

Here is an example of How to use POST and a Server Side Functions using Supabase.

  • First i create a table call ps (Apply RLS [Row Level Security to anon users and only for SELECT ]) because it's for a Splash Screen. And a bucket to store the Lobo.png call ps (Same RLS)
Screens for step 1





  • Now create the Server Side Function.
Server Side Fn explained
  • Fn: Create function called tss that receive an argument called xjgt
  • if xjgt = tclt then return the first value of column i1 from table ps else return a text saying "Sorry... im no so basic..."
Screens of Fn

PL/PGSQL code:


CURL to call it and description:

  • Now proceed to AppInventor and create the logic and UI. (It explains itself)
Screens from AppInventor


  • Now test on phone
Screen from my phone in companion

  • Details to be considered:
Encryption to send and receive
  • You can Encrypt the Response Content with pgcrypto on the same Server Side function, and decrypt in client side.
  • Also encrypt the headers and values to send data and decrypted with the same Server Side function.
  • For that, you i'll need Private and Public key encryption from this Extension from @vknow360
  • Use it
Database management
  • Nobody need to know your DB Schema, Table Names, Columns Names, etc. (even in Team Work They must use difficult nomenclatures and document the code well.)
  • If you are in a team (or not) Use the description fields to put the relevant information of the table, column, etc.
  • Not the same for (inside) AppInventor (Reverse Engineer attacks)
Inside AppInventor
  • Like i say in previous response, you can secure encrypt your Api Keys using tecniques for files and contents.
  • Do not comment your code inside code.
  • Try to use Local and not Global variables (with difficult nomenclatures) this difficult Reverse Engineer attacks.
  • Also try to use Functions that receive arguments to manage all that local variables (Sync... and Async...). this difficult more the Reverse Engineer attacks.
  • Even you can use WebViewer to interact with JS code (only) to send and receive and manage data inside blocksto expand the capabilities of AppInventor
Security Concerns
  • Yes... It's hard work, but... if you want be secure under Zero Trust principle.. You must do it.
  • I found it useful, here is your like.
  • ChatGPT will take your job.
  • Watchmen rules.
0 voters
1 Like

Thank you for your reply. I've been reading it a few times, but it's difficult at my level. I'll study more about the relevant topics based on what you've written. Thank you again for taking the time to write a long article.

1 Like
  • That's all about!!; sharing knowledge, growing as a professional, person and human.

Helping new generations to be better than us.

It is true that today you are at a low level, but tomorrow you will not be. Keep in mind that what took me 37 years to learn, you could learn in less.

The best way to teach is by guiding, not giving the task done, and motivating to never stop learning, and the best way to learn is by investigating, thinking, meditating and breaking things. :grin:

I am also at a low level about AppInventor, Java, Extensions, Rush, etc.
But it won't be forever.

  • Don't forget to vote for any of the options.

As well as, use all the tools offered by the forum to keep the posts legible, clear and clean.

  • (Sorry, I'm old school)
1 Like

What this community knows about encryption is discussed in the links.

Remember no method is perfect and if it is very sensitive data I wouldn't post it using tools available.
Anything can be hacked although these methods do add a layer of security. If you are really concerned, simply don't post it.


100% agree. - No data is silly -

  • Very Sensitive Data: It is a field of study that still gives a lot of talk despite all the advances, including hardware encryption.

  • Store now and Decrypt later; it is the term of this era.

  • As I said previously, it's just about being as safe as possible.

1 Like