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. LieGrue, strub > Am 12.05.2017 um 13:06 schrieb Romain Manni-Bucau <[email protected]>: > > 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 <[email protected]>: > >> 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 <[email protected] >>> : >>> >>> 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 <[email protected] >>> : >>>> >>>> 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) <[email protected]> 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) >>>>> >>> >> >>
