Hi Akihiro, Sending an encrypted password over a non secure connection isn't really a safe way to protect the system. Attackers can just read the encrypted password off the wire and use that! Plus users would also be vulnerable to a man in the middle attack. The right way to protect client-server communication is to use transport layer security - see https://geode.apache.org/docs/guide/latest/managing/security/implementing_ssl.html .
On Tue, Dec 26, 2017 at 5:09 PM, Akihiro Kitada <[email protected]> wrote: > Hello Sudhir, > > As far as I know, AuthInitialize is executed at client side. If decrypting > passwords at client side via AuthInitialize, those passwords may be > conveyed to server side with plane text unencrypted format via network, > according to the implementation in AuthInitialize. > > If you don't want to convey those passwords with plain text format via > network, anther way is to de/encrypt passwords at server side > SecurityManager implementation at "authenticate" method. > > Thanks, regards. > > > > -- > Akihiro Kitada | Staff Customer Engineer | +81 80 3716 3736 > <+81%2080-3716-3736> > Support.Pivotal.io <http://support.pivotal.io/> | Mon-Fri 9:00am to > 5:30pm JST | 1-877-477-2269 <(877)%20477-2269> > [image: support] <https://support.pivotal.io/> [image: twitter] > <https://twitter.com/pivotal> [image: linkedin] > <https://www.linkedin.com/company/3048967> [image: facebook] > <https://www.facebook.com/pivotalsoftware> [image: google plus] > <https://plus.google.com/+Pivotal> [image: youtube] > <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl> > > > 2017-12-27 5:04 GMT+09:00 Sudhir Babu Pothineni <[email protected]>: > >> Thanks Dan. >> >> Yes I am aware it’s not so secure, I am just trying to meet the company >> policy of not directly hardcode the password in a file, encrypted password >> will be ok :). I will implement the AuthInitialize. >> >> >> On Dec 26, 2017, at 1:34 PM, Dan Smith <[email protected]> wrote: >> >> Hi Sudhir, >> >> You can do pretty much anything you want by implementing your own >> AuthInitialize on the client. The AuthInitialize generates the credentials >> to send to the server. So for example you could implement an AuthInitialize >> that reads and encrypted password, decrypts it, and sends it to the server. >> >> Encrypting your password won't make your system more secure unless you >> are using something other than a file to store your encryption key though. >> If your encryption key is just in a file than an attacker just needs to >> steal that file as well. >> >> -Dan >> >> On Tue, Dec 26, 2017 at 10:45 AM, Sudhir Babu Pothineni < >> [email protected]> wrote: >> >>> It seems password encrypt/decrypt is deprecated Apache geode 1.3. >>> >>> What is the alternative if I want hardcore encrypted password in a >>> configuration file of geode client implementation? >>> >>> Thanks >>> Sudhir >>> >>> On Dec 22, 2017, at 12:35 PM, Jens Deppe <[email protected]> wrote: >>> >>> Great. Thanks for the feedback about the documentation! >>> >>> --Jens >>> >>> On Fri, Dec 22, 2017 at 10:27 AM, Sudhir Babu Pothineni < >>> [email protected]> wrote: >>> >>>> Thanks Jens! Its working. >>>> >>>> I think in the doc these three parameter should be mentioned together >>>> somewhere, Otherwise its not intuitive, although there is lot of >>>> description around SecurityManager. >>>> >>>> security-manager=org.apache.geode.examples.SimpleSecurityManager >>>> >>>> security-username=admin >>>> >>>> security-password=xyz1234 >>>> >>>> On Fri, Dec 22, 2017 at 10:36 AM, Jens Deppe <[email protected]> wrote: >>>> >>>>> Hi Sudhir, >>>>> >>>>> You should find two sample SecurityManagers in the code. >>>>> >>>>> The first is *org.apache.geode.examples.SimpleSecurityManager* [1]. >>>>> This manager will simply compare the username/password and >>>>> *authenticate* if they match. In addition if the username matches a >>>>> required permission, then the request is also *authorized*. For >>>>> example, if the credentials are *'admin/xyz1234'* then it will never >>>>> authenticate. If the credentials are *'dataRead/dataRead'* then the >>>>> user would be authenticated for all operations requiring DATA:READ >>>>> permissions. Although it's simplistic, this manager is very useful for >>>>> testing your whole flow and validating specific permissions for various >>>>> operations. >>>>> >>>>> The other SecurityManager provided is >>>>> *org.apache.geode.examples.security.ExampleSecurityManage*r [2]. This >>>>> manager takes as input a JSON file which maps users -> roles -> >>>>> permissions. The javadoc has examples of using this [3]. >>>>> >>>>> --Jens >>>>> >>>>> [1] https://github.com/apache/geode/blob/develop/geode-core/ >>>>> src/main/java/org/apache/geode/examples/SimpleSecurityManager.java >>>>> [2] https://github.com/apache/geode/blob/develop/geode-core/ >>>>> src/main/java/org/apache/geode/examples/security/ExampleSecu >>>>> rityManager.java >>>>> [3] http://geode.apache.org/releases/latest/javadoc/org/apac >>>>> he/geode/examples/security/ExampleSecurityManager.html >>>>> >>>>> On Fri, Dec 22, 2017 at 7:55 AM, Sudhir Babu Pothineni < >>>>> [email protected]> wrote: >>>>> >>>>>> let me extend my question: >>>>>> >>>>>> Does Geode has any Default/SimpleSecurityManager implementation? >>>>>> >>>>>> On Fri, Dec 22, 2017 at 9:15 AM, Sudhir Babu Pothineni < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I am working on Geode(1.2) authentication. According to the doc, >>>>>>> https://geode.apache.org/docs/guide/12/managing/securit >>>>>>> y/implementing_authentication.html >>>>>>> >>>>>>> I put gfsecurity.properties: >>>>>>> >>>>>>> security-username=admin >>>>>>> security-password=xyz1234 >>>>>>> >>>>>>> Any other parameters needed? >>>>>>> >>>>>>> because of some reason Geode working without authentication, >>>>>>> gfsecurity.properties is in the class path. I am expecting JMX manager >>>>>>> also >>>>>>> should work on these credentials. >>>>>>> >>>>>>> Thanks for the help >>>>>>> Sudhir >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
