This is a common problem and there are some common guidelines that allow
you to run your program almost anywhere.
Store your passwords in an external file.
The passwords must be encrypted using at least 1024 bit encryption with
some sort of salt. AES is probably your best bet.
The file must be rea
> From: Kent Borg [mailto:kentb...@borg.org]
>
> On 01/31/2015 06:03 PM, Edward Ned Harvey (blu) wrote:
> > Depends on a lot of stuff. What language? Running on a system you own,
> > or deployed to someone else, etc?
>
> Daemons, written in Python, on a machine I fully control.
The best you can
On 1/31/2015 6:25 PM, Kent Borg wrote:
Daemons, written in Python, on a machine I fully control.
If you fully control it then you don't need authentication.
Because this is only used to communicate within the machine, no one
else cares whether it changes. A file with narrow permissions is
sa
On 01/31/2015 06:30 PM, Gordon Marx wrote:
None of that matters.
Huh?
Code goes in version control. Secrets that you want to keep secret don't.
Therefore, you can't put secrets into your code.
Yes, that's why I brought up the question. We agree.
Write the username and password into a con
None of that matters. Code goes in version control. Secrets that you want to
keep secret don't. Therefore, you can't put secrets into your code.
Write the username and password into a configuration file, get the username and
password from the environment, or use a non-password auth mechanism lik
On 01/31/2015 06:03 PM, Edward Ned Harvey (blu) wrote:
Depends on a lot of stuff. What language? Running on a system you own,
or deployed to someone else, etc?
Daemons, written in Python, on a machine I fully control.
-kb
___
Discuss mailing list
D
> From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On
> Behalf Of Kent Borg
>
> My program already has to hope that its program files are secured by the
> hosting OS, but at least if it isn't opening up a network port it stays
> a rather contained problem.
Depends on a lot of stuf
On 1/31/2015 1:53 PM, Kent Borg wrote:
How about this: Give every boot, of every box running the code, its own
unique password.
If Postgres reads the random password before the password randomizer
finishes then Postgress will have the previous boot's password or an
incomplete password from a
All I am doing is connecting the server with the client code, on the
same machine. I don't care what the password is, only that the two
agree, on any given box.
How about this: Give every boot, of every box running the code, its own
unique password.
At every boot, create a new password in a
Rather than password authentication you should look at other mechanisms
like SSH's public key authentication or Kerberos keytabs. What's
probably better is to use a role-based access control mechanism where
only processes with the requisite roles can access the secure system.
--
Rich P.
__
Set up postgres to only allow connections from the loopback. Put the db
credentials in a file, then rely on file-system permissions and/or
SElinux to prevent access to that file from other processes on the
system. This is the sort of thing SELinux is really designed for.
Matt
On 1/31/2015 10:56
FWIW, in PHP you often put the PostgreSQL user credentials in the code.
Usually a config file somewhere. You can also place sensitive files outside of
your web root with proper permissions. If all running on a local box I don’t
open the ports or set the db config to allow other connections.
Related to my previous database questions...
Normally I think of a program as trusting itself, having some integrity,
maybe not even having gaping bugs or security holes. But what if I the
program I am writing is talking to another, such as Postgres? Postgres
has the ability to do passwords, s
13 matches
Mail list logo
