[Gambas-user] A couple of ?s about encryption

Tobias Boege taboege at ...626...
Sun Aug 13 22:03:50 CEST 2017


On Sun, 13 Aug 2017, mikeB wrote:
> eGreeetings,
> I am starting a project that involves encryption of passwords and user names
> - storing and recalling them.
> 
> 1st ? = i noticed Gambas can save and recall files from a ".hidden"
> directory. If the files are encrypted before
> saving to a hidden dir - how secure is this?  In other words would an
> experienced coder be able to find and
> copy these files? Would this be the secure/ recommended way/ place to store
> these files?
> 

The .hidden directory is a normal directory inside your project directory.
As the documentation states [1], it contains files that should not go into
the Gambas executable. If you store files in there you will in general NOT
have them available when your project executes.

And something else that is true for all directories in the your project:
you should not suppose that any of them is writable at runtime. You can
only use them to supply initial encrypted data that is never altered by the
program (if that's a good idea depends on your application).

[ The whole truth is: you can still access .hidden at runtime and write to
any directory in your project tree IF your project is run from the project
directory (you have to use absolute paths from Application.Path then).
There is no (sane) way to write to project directories from an executable
archive (.gambas file). The .gambas files are archives of your project
directory, which the interpreter unpacks in memory. Changing an in-memory
directory would have no effect on the actual directory stored inside the
archive, so it is forbidden from the start. ]

But yes, the interpreter can unpack executable archives, so you should
suppose that everyone will be able to figure out how to do it as well
(they just have to read the Gambas source code). Your data is not protected
whatsoever, except by the encryption you apply.

> 2nd ? = shelling out to the "gpg" command line to encrypt / decrypt the
> password files be a secure way of
> doing this or is there a better way (i.e. writing the encryption code within
> the Gambas project)?
> 

I can't tell you if it's secure. First of all because I don't know enough
about security, and second because we don't know enough about your situation.
I remember hearing that security is not a yes/no question. It depends on
where your threat comes from (and if you have identified all threats).
E.g. suppose that you call "gpg ..." from your program. I'm an attacker and
your program allows me to run it(!) (whether this is the case you didn't say).
Then I can just modify the PATH environment variable to supply my own version
of "gpg" which logs all the passwords you send to it.

To write encryption code in your project, there is gb.openssl. But be warned
that you have to know what you're doing. For example there are surprisingly
many (at least to me when I first read them) considerations to be done when
hashing passwords (have a look at [2]). Commonly used hashes are considered
*too fast* to be secure, for instance. The site recommends, among others,
scrypt for hashing passwords. OpenSSL seems to support it but gb.openssl
apparently does not. I may have to look into that sometime.

> 3rd ? = Now a GNU question from a real newbie on this subject. With this
> type of program (Protected Passwords)
> how in the heck could it be released under GNU? Or should it be? Don't
> understand how it could possibly be
> "protected" if the source code was available to all?
> 

You mean the GPL. Again, I'm no lawyer, but this shouldn't be a problem,
unless you want to ship passwords directly with your source code. Why
would you do that? Passwords are (normally) user-supplied data, so let
the user deal with them, e.g. by storing them away from your project
source code inside a directory in the user's $HOME, or something. Your
program should just contain the logic to treat passwords, not their
values. The security of modern encryption is not derived from their
*algorithm* but from *keys*, additional data that is provided to the
algorithm alongside the data to be encrypted and those keys have to
be kept secret (and not distributed with source code). This is called
Kerckhoff's principle [3]. So, if you're doing it right, your source
code should be free of sensitive information.

Regards,
Tobi

[1] http://gambaswiki.org/wiki/doc/project_structure
[2] https://crackstation.net/hashing-security.htm
[3] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk




More information about the User mailing list