Well, plain masterpassword in some file -> shared secret between DB and file system. encrypted masterpwd in some file + application token -> shared secret between DB, file system, application, + + +. The app could literally pull it from anywhere, including a remote system like vault. So it's surely not worse than the plain pwd option.
If one doesn't want to leverage a more dynymic token then just use a static string in your app and be done. LieGrue, strub > Am 12.05.2017 um 15:11 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > sure, point is master key in clear or not doesnt change anything. Security of > such a system is only guaranteed by the split of the master key and the > encrypted value but when you have both at the same location security is not > more a question. > > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > > 2017-05-12 13:50 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > With your take even pgp is unsecure! > > Because if you can get the private key file AND you know the password, then > you can encrypted everything. > > Ofc there is no absolute security, but given enough chained steps which are > cryptographically strong in itself makes it still so much better than > plaintext. > > LieGrue, > Strub > > > > -------------------------------------------- > On Fri, 12/5/17, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Subject: Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client > encryption handling > To: "dev@deltaspike.apache.org" <dev@deltaspike.apache.org> > Date: Friday, 12 May, 2017, 13:28 > > 2017-05-12 13:16 GMT+02:00 Mark > Struberg <strub...@yahoo.de.invalid>: > > > Well, not 100% > d'accord. > > > > Of > course it is just a split-secret security. > > Parts of the secret are in a file, others > in the application. > > An attacker would > need to gather > > * the master.hash > file > > * the application (or at least the > masterSalt text or algorithm) > > * the > encrypted date (Database etc). > > > > So he actually needs quite some access > already! > > This is surely better than a > cleartext password stored in the database > > which everyone could see. > > > > But of course, once > an attacker comes over the debug port, etc - then ALL > > security is gone. > > I > think our approach is not much behing Hashicorp Vault in > that regard > > (you could btw also gather > parts of the secret from a remote box in your > > code). > > After all the > ONLY secure system is if you have a HSM (a hardware > security > > device) which has it's OWN > pin entry (!) AND you only access the > > > information via a consumable 1-time security token. > > But as long as e.g. the database is just > secured with a static text > > > (username/password) then everything else is mathematically > breakable. > > > > Still > there is imo a HUGE difference between a cleartext password > and a > > split-secret approach. > > > > Nop, not > theorically. I understand it feels different, kind of > "oh a > password" vs > "what's that text?" but if you have accesses > to read the clear > password then the > encrypted one is as easy to get. All this security relies > on the local access (which gives you access to > the files, db etc...), all > other things put > around is cosmetic to make people comfortable with it. > More it is split longer it will be to get but > since the algo is predictable > then not more > secured until you rotate the strategy very often, like > each > minute. > > > > > > LieGrue, > > strub > > > > > Am 12.05.2017 um 13:06 schrieb Romain > Manni-Bucau <rmannibu...@gmail.com > > >: > > > > > > I think until we support a hsm > strategy- which relies on infra more than > > > encryption - we can just put it all > in clear, security level will be 1-1. > > > > So IMHO it is really "do people feel more > comfortable with unclear text > > > even > if it is as secured as clear text". If we start to go > until "if I'm > > in > > > the app" then the security is > compromished anyway even if it is sha > > > etc... > > > > > > > So concretely I think it is fine but if the proposed action > is just to > > move > > > > to sha-256 or another impl it doesnt hurt much to do, > if the action is > > more > > > impacting like creating 1000 files of > 1M with a very specific stratégy to > > > > read a byte in each of them depending the file > timestamp and jumping on a > > > leg > I'm not sure it does worth it since the assumption to > access the > > clear > > > > password is exactly the same as having it in clear. > > > > > > makes > sense? > > > > > > > > > > > > > > Romain Manni-Bucau > > > @rmannibucau > <https://twitter.com/rmannibucau> | > Blog > > > <https://blog-rmannibucau.rhcloud.com> > | Old Blog > > > <http://rmannibucau.wordpress.com> | > Github <https://github.com/ > > > rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> > | JavaEE Factory > > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > > > 2017-05-12 > 12:57 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > > > > > >> Btw, > the date, etc should of course _not_ get handed over as > masterSalt > > in > > > >> cleartext! > > >> If someone > would debug the app (also stealing the jars) then a > string > > like > > > >> "my app-2017-05-12-192.168.4.123 > > >> Then it would be easily > recognisable how the pattern looks like. > > >> But if you just apply a sha1 on > that string, then nobody could tell what > > >> is behind is. And you could hie > this information pretty well in your > > > >> application somewhere. > > > >> > > >> Of course that does > still not create absolute security (there is no such > > >> thing like an absolute > security). > > >> But an attacker > would need > > >> * the actual > encrypted secret information string > > > >> * the ~/.deltaspike/master.hash file (or wherever > you store it, this is > > >> just the > default) > > >> * the fully running > application (with most business applications this is > > >> not as easy as it sounds - try to > install a big app on some fresh > > > server...) > > >> * the algorithm of > the masterSalt. > > >> > > >> > > >> > LieGrue, > > >> strub > > >> > > >> > > >> > > >>> > Am 12.05.2017 um 12:31 schrieb Mark Struberg <strub...@yahoo.de.INVALID > > >>> : > > > >>> > > >>> Txs Rudy, any > help is welcome! > > >>> > > >>> > > > >>>> - Why hashing with SHA-1 > > >>> > > > >>> I guess you mean the master hash? > > >>> > > > >>> Oki, there are 3 encryption tokens in place: > > >>> > > > >>> 1.) The master password provided by the user in > the CLI when creating > > >> the > master password (writing the CLI right now): > > >>> > > > >>> $> java -jar apache-deltaspike-core-impl.jar > encode -masterPassword > > >> > myMasterPassword -masterSalt > someSecretOnlyKnownToMeAndTheApplication > > >>> > > > >>> The masterPassword does NOT get stored > anywhere. Neither in plain text > > > >> nor encrypted. It's _only_ known to the user > who creates the masterHas. > > > >>> > > >>> 2.) The > masterPassword ("myMasterPassword") gets hashed > and THIS will > > be > > > >> used to encrypt/decrypt the user passwords in the > end. > > >>> Of course the hash > does _not_ get stored directly but only encrypted > > via > > >> the > master Salt > ("someSecretOnlyKnownToMeAndTheApplication"). > > >>> The key in the > ~/.deltaspike/master.hash properties file is the the > > hash > > >> hashed > again: effectively hash(hash(masterPassword)). That way > you > > cannot > > > >> get back from the key in the master.hash file to > the key used to decrypt > > >> the > hash of the masterPassword > > > >>> > > >>> 3.) the hash > of the masterPassword (as stored in the master.hash file > > >> encrypted via the masterSalt) is > then used to encrypt/decrypt the actual > > > >> security, e.g. a jdbc.user.password. > > >>> There is again a CLI to > encode it > > >>> $> java -jar > apache-deltaspike-core-impl.jar encode -plaintext > > >> ThisIsMyDatabasePassword > -masterSalt someSecretOnlyKnownToMeAndTheA > > >> pplication > > > >>> > > >>> > > >>> > > > >>> To give more protection, the masterSalt is only > known to the > > >> administrator and > the application. This could also include installation > > >> dependent information like the > MAC address, the UID of the /dev/sda > > > disk, > > >> etc. Even the current > day! That way you can force a master password hash > > >> which is only valid for a single > day, of course without having to > > > >> re-encrypted information stored somewhere in your > DB etc. every day. > > >>> > > >>> > > > >>> Makes sense? > > > >>> > > >>> LieGrue, > > >>> strub > > > >>> > > >>> > > >>> > > > >>> > > >>>> - When I > use AES, I always use an Initialization Vector (IV) and > > specify > > > >>>> the Block mode and padding. > > >>> > > > >>> > > >>> Glad to > improve that part! > > >>> > > >>> > > > >>>> Am 11.05.2017 um 21:11 schrieb Rudy De > Busscher < > > rdebussc...@gmail.com > > >>> : > > > >>>> > > >>>> Hi > Mark, > > >>>> > > >>>> As I'm working lately > quite a lot with security and encryption, I was > > >>>> interested in your > implementation. > > >>>> > > >>>> I don't have the time > today to look into details, but I already have > > >> some > > > >>>> questions > > > >>>> > > >>>> - Why > hashing with SHA-1 (not a secure hashing algorithm anymore). > Why > > >> the > > > >>>> additional hashing (before AES encryption) > as you mention that we try > > >> > only > > >>>> to > 'obscure'. > > >>>> - > When I use AES, I always use an Initialization Vector (IV) > and > > specify > > > >>>> the Block mode and padding. > > >>>> > > > >>>> I'll try to find some time this weekend > to study the code in detail. > > > >>>> > > >>>> best > regards > > >>>> Rudy > > >>>> > > > >>>> > > >>>> On 11 > May 2017 at 19:05, Mark Struberg (JIRA) <j...@apache.org> > > wrote: > > > >>>> > > > >>>>> > > > >>>>> [ > https://issues.apache.org/jira/browse/DELTASPIKE-1250? > > >>>>> > page=com.atlassian.jira.plugin.system.issuetabpanels: > > comment-tabpanel& > > > >>>>> > focusedCommentId=16006784#comment-16006784 ] > > >>>>> > > > >>>>> Mark Struberg commented on > DELTASPIKE-1250: > > >>>>> > ------------------------------------------- > > >>>>> > > > >>>>> A first design proposal can be found on > my github repo > > >>>>> https://github.com/struberg/deltaspike/tree/DELTASPIKE-1250 > > >>>>> > > > >>>>> Will now add a main method to generate > the master password and > > encrypt > > >>>>> content > > >>>>> > > > >>>>>> create a master/client encryption > handling > > >>>>>> > ------------------------------------------ > > >>>>>> > > >>>>>> > Key: DELTASPIKE-1250 > > > >>>>>> URL: https://issues.apache.org/ > > >>>>> > jira/browse/DELTASPIKE-1250 > > > >>>>>> Project: > DeltaSpike > > >>>>>> > Issue Type: New Feature > > > >>>>>> Components: > Configuration > > >>>>>> > Affects Versions: 1.7.2 > > > >>>>>> Reporter: Mark > Struberg > > >>>>>> > Assignee: Mark Struberg > > > >>>>>> Fix For: 1.8.0 > > >>>>>> > > >>>>>> > > >>>>>> For storing > passwords in our configuration I'd like to implement a > 2 > > >>>>> stage approach > to symmetric encryption. > > > >>>>>> The current ideas is to have an > encrypted has derived from a master > > > >>>>> password and box-locale information > (MAC, IP, expiry date, etc). > > > >>>>>> This encrypted sequence is > different on every box. But the decrypted > > >>>>> hash is not. > > >>>>>> > > >>>>>> With this hash we > can encode a user password, which is then ofc the > > >> same > > > >>>>> on different boxes. > > >>>>>> Of course all > that is just security by obscurity, but it's still > > much > > > >>>>> better than plaintext and even close to > vault. > > >>>>>> After > all, the only really secure way is using a hardware crypto > box > > >>>>> plus the user > has to manually provide a password and not using static > > >>>>> passwords but 1-time > consumable tokens. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> This message was sent by Atlassian > JIRA > > >>>>> > (v6.3.15#6346) > > >>>>> > > >>> > > > >> > > >> > > > > >
