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
-~----------~----~----~----~------~----~------~--~---

Reply via email to