If this is just a distribution issue, why don't you just create an
example model and not distribute the actual one ? You make a 000-
connections.example.py which has a commented db=SQLDB(gibberish) in it
in the models dir (it has to be commented so you don't write over the
real one). The actual 000-connections.py could be a softlink to the
actual thing (so you don't accidentally zip it or to avoid it being
grabbed by the web2py admin).
On Oct 16, 10:10 pm, mdipierro <[EMAIL PROTECTED]> wrote:
> That would just replace the password with the md5 of the password. for
> practical purposes the md5 would be your password and you have not
> made one step forward.
>
> Once again... whatever gibberish you put in the SQLDB
>
> db=SQLDB(gibberish)
>
> this does not prevent an attacker from doing
>
> for table in db.tables: db[table].drop()
>
> There is no security in protecting SQLDB(....). The security is in
> preventing attackers from getting to this file.
>
> Massimo
>
> On Oct 16, 2:41 pm, Pai <[EMAIL PROTECTED]> wrote:
>
> > So what would the connection string look like?
>
> > db=SQLDB("mysql://username:[md5 password [EMAIL PROTECTED]:port/dbname")
>
> > On Oct 16, 1:28 pm, "Phyo Arkar" <[EMAIL PROTECTED]> wrote:
>
> > > So you can always use any algorighm (SHA , MD5) which already comes with
> > > python.
>
> > > On Thu, Oct 16, 2008 at 6:26 PM, Pai <[EMAIL PROTECTED]> wrote:
>
> > > > That's really all i'm looking for actually. The code will get pass
> > > > around to a couple of developers. I don't want the password to show
> > > > up in clear text.
>
> > > > On Oct 16, 11:20 am, "Phyo Arkar" <[EMAIL PROTECTED]> wrote:
> > > > > Yes , I couldn't agree more with you massimo.
>
> > > > > Security by Obscurity Fails Horribly .
>
> > > > > Pai what you looking will only prevent at the Source Code level , and
> > > > > any
> > > > > sniffer can grep that encrypted string and can decrypt (there are
> > > > > alot of
> > > > > MD5 decryption bots out in the internet, use one)
>
> > > > > On Thu, Oct 16, 2008 at 4:16 PM, mdipierro <[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > > This is a false security mechanism. Consider a communication between
> > > > > > A(lice) and B(ob). It can be protected against a third party (C) by
> > > > > > encrypting information (for example the password). It is logically
> > > > > > impossible to protect B from A.
>
> > > > > > Even if A only stores the encrypted password there are a number of
> > > > > > possible scenarios:
>
> > > > > > 1) it still needs to decrypt the password to authenticate to the
> > > > > > database
> > > > > > 2) it can authenticate to the database using the encrypted password
>
> > > > > > In both cases an attacker who gets control of A can access the
> > > > > > database. If A can access the attacker can access. Period.
>
> > > > > > Any other argument is just a distraction.
>
> > > > > > JBoss is just hiding the problem from storing the password into the
> > > > > > mechanism from decrypting the password and sending it to the
> > > > > > datastore. This behavior could be replicated in web2py but it would
> > > > > > not give you any real protection. This security via obfuscation.
>
> > > > > > Massimo
>
> > > > > > On Oct 16, 10:40 am, Pai <[EMAIL PROTECTED]> wrote:
> > > > > > > Ok so maybe this would be a better way to phrase the question. Is
> > > > > > > there a way in web2py to not write password in clear text. I know
> > > > > > > that you can do it in jboss..
>
> > > > > > > something like this..
>
> > > > > > >http://www.jboss.org/community/docs/DOC-9703
>
> > > > > > > Thanks!
>
> > > > > > > On Oct 15, 9:39 pm, mdipierro <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > This is not a web2py issue.
>
> > > > > > > > There are two weak points.
>
> > > > > > > > 1) The connection between the web server(s) and the database
> > > > server.
> > > > > > > > You can secure it by using ssh, but the most common solution is
> > > > have a
> > > > > > > > local network behind the firewall and create firewall rules only
> > > > allow
> > > > > > > > traffic from the web server reach the database server. Even
> > > > > > > > better
> > > > > > > > would be to give your web server(s) a second network card that
> > > > > > > > is
> > > > ONLY
> > > > > > > > connected to the database server.
>
> > > > > > > > 2) No matter what you do, the web server needs to connect to the
> > > > > > > > database server. If somebody hacks into the web server, they can
> > > > talk
> > > > > > > > to your database. Nothing protects you for it. You would have
> > > > > > > > the
> > > > same
> > > > > > > > issue with Java or PHP. All web applications suffer from this
> > > > issue.
> > > > > > > > The only thing you can do is to make sure your web server is as
> > > > secure
> > > > > > > > as possible:
>
> > > > > > > > a) use a secure framework (web2py i very advanced in this
> > > > > > > > respect,
> > > > > > > > even the http accept-language field gets validated, you can
> > > > > > > > check
> > > > what
> > > > > > > > other frameworks do)
> > > > > > > > b) disable every other service (do not even allow ssh
> > > > > > > > connections
> > > > from
> > > > > > > > the internet, only from the internal private network)
> > > > > > > > c) do not run multiple apps on the web server so, if the hack
> > > > > > > > into
> > > > > > > > one, they cannot get into the databases of the others.
> > > > > > > > d) Do not run any PHP or ASP app on the same server running
> > > > > > > > web2py.
> > > > > > > > There are many of them and many have known vulnerabilities that
> > > > > > > > vulnerability scanners know how to exploit.
> > > > > > > > e) store the database on a filesystem that has journaling and
> > > > > > > > you
> > > > can
> > > > > > > > go back to a previous state and backup your database
> > > > > > > > f) have an intrusion detection system that looks for scans and
> > > > blocks
> > > > > > > > the IP of the scanner before he can get in.
> > > > > > > > g) setup a honeypot so they want to hack, they hack into that
> > > > > > > > first
> > > > > > > > and you can take action.
>
> > > > > > > > There is no solution to this problem. Only good practice.
>
> > > > > > > > Massimo
>
> > > > > > > > On Oct 15, 8:50 pm, morningovermidnight <
> > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
>
> > > > > > > > > Massimo
>
> > > > > > > > > I too am concerned about the security of my DB password from
> > > > prying
> > > > > > > > > eyes. I understand that when the database connection url uses
> > > > > > > > > localhost as in ->
> > > > db=SQLDB('mysql://username:[EMAIL PROTECTED]:
> > > > > > > > > 3306/mydatabase'), when I upload to a shared webhosting
> > > > > > > > > server,
> > > > to
> > > > > > > > > connect to the DB I am using my domain as in ->
> > > > db=SQLDB('mysql://
> > > > > > > > > username:[EMAIL PROTECTED]:3306/mydatabase'<
> > > > http://username:[EMAIL PROTECTED]:3306/mydatabase%27>).
> > > > > > Is this secure?
> > > > > > > > > It does make me wonder if I am sending this information in the
> > > > > > > > > clear. :-/
>
> > > > > > > > > On Oct 15, 8:50 pm, mdipierro <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > > > In a typical production setting you would have a web server
> > > > exposed
> > > > > > to
> > > > > > > > > > the internet and a secure local network. The connection with
> > > > the
> > > > > > > > > > database should go only over the local network. ssh will
> > > > protect
> > > > > > you
> > > > > > > > > > from employees snooping around (and stealing database
> > > > > > > > > > password)
> > > > but
> > > > > > > > > > will make the database connection more of a bottleneck. Nor
> > > > > > > > > > ssh
> > > > nor
> > > > > > > > > > password will protect you in case somebody hacks into the
> > > > > > > > > > web
> > > > > > server
> > > > > > > > > > and acquires the credentials of the web server. If your web
> > > > > > > > > > app
> > > > can
> > > > > > > > > > access the DB, the attacker can too. To some extend one can
> > > > also
> > > > > > > > > > configure the db engine to accept only connections form
> > > > > > > > > > certain
> > > > IPs
> > > > > > > > > > and limit the roles of the user associated to the web app.
>
> > > > > > > > > > This is why it is very important to try prevent
> > > > > > > > > > vulnerabilities
> > > > in
> > > > > > web
> > > > > > > > > > apps.
>
> > > > > > > > > > Massimo
>
> > > > > > > > > > On Oct 15, 5:50 pm, achipa <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > > > > Depends of why he needs to hide the connection parameters
> > > > > > > > > > > in
> > > > the
> > > > > > first
> > > > > > > > > > > place...
>
> > > > > > > > > > > Yarko: you can always do mysql over ssh. Not for the
> > > > > > > > > > > faint at
> > > > > > heart,
> > > > > > > > > > > but it IS paswordless and secure.
>
> > > > > > > > > > > On Oct 15, 9:44 pm, yarko <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > > > > > I think the issue is: if the db server is on the same
> > > > > > > > > > > > box,
> > > > and
> > > > > > the
> > > > > > > > > > > > box is secure, then that's a limited issue;
> > > > > > > > > > > > If the db server is accross a network, then nothing
> > > > > > > > > > > > web2py
> > > > (or
> > > > > > > > > > > > anything else connecting) can help, without the support
> > > > > > > > > > > > of
> > > > the
> > > > > > db -
> > > > > > > > > > > > this practically means you find an alternate way of
> > > > > > authenticating on
> > > > > > > > > > > > the db .
>
> > > > > > > > > > > > On Oct 15, 2:05 pm, mdipierro <[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > > > > > > > > > No that I know of.
>
> > > > > > > > > > > > > On Oct 15, 11:42 am, Pai <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > > > > > > > Is there a way to hide password in the
> > > > connection-string?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
