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'). 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 -~----------~----~----~----~------~----~------~--~---
