Re: [Firebird-devel] On-disk Encryption
On Friday, August 21, 2015, Scott Morgan wrote: > > Q1 : 4, I don't expect NSA defeating crypto[0], but enough to keep > casual eyes away from expensive data. > > Q2 : 5, It's a must. Whether the key is somehow held internal to the > .FDB file (with it's own pswd, no system wide account access, naturally) > or passed in via connection data, isn't an issue[1], but the DB must be > available to the apps depending on it with zero user intervention. > > Scott > > [0] For deployment to sites out of our control, in the end there's no > technical way to truly hide the data, obviously. But we're also not > talking about skilled hackers either, just average users. Hell, XOR > would probably suffice, but something like ChaCha would be preferred. > > [1] Although, would prefer things like GBAK, ISQL, etc. to still be usable. > > ChaCha20 is a stream cipher that generates a pseudo random byte stream that is XORed with the plaintext to form the ciphertext. If the same initial state () is used more than once, which is necessary to re-encrypt a changed page, XORing two encrypted page image versions results is the same as the XOR of the two plaintext page images. From that and a knowledge of Firebird page format, and security is blown. This is not a reflection on ChaCha20, but just an example of tge dangers of using a good algorithm inappropriately. -- > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Passwords and Security, Revisited
On 20-8-2015 13:49, James Starkey wrote: > SHA1 produces a 160 bit hash or 2^160 possible values. To search the > hash space, on average you have to try half of these, or 2^159 probles. > A decimal digit requires about three and a half bits, so round that up > to four. So expressing the number of probes in decimal (or hex) would > require 2^155 digits. If we assume there are four billion computers on > earth. That means that each computer would need to store 2^123 digits. >A gigabyte is 2^9, so each compuer would have to have 2^114 GB of memory. > > The probability of breaking the hash is the reciprical of that number, > which will have approximately that number of zeros after the decinal > point. For convenience, lets assume that the probability of guessing a > SHA-256 hash is zero, so the difference between SHA-1 and SHA-256 is the > same as the probablity of guessing a SHA-1 hash, which is a number too > small to be expressed except exponentially. Ah, now I see, thanks! Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files
Problem: How to start server on encrypted database files with a human to supply a password. Idea: Assume SRP is being used for authentication and that all (or most or some) are using long, randomly generated passwords from a client-side vault (or equivalent). This means that it is safe to store account/salt/verifier triplets in an unencrypted file external to the database (if you want to get fussy, hash the accounts). The server starts up unabled to access the database file. In this state, the first SRP connection request is processed through the external verifier file. After a secure connection is established with the client, the server requests that the client send a hash of the client's password that is used to open a server-side client specific vault containing the generated password for the master vault that contains the database file encryption key. The verifier file would be recreated by the server whenever a verifier changed. The account specific server-side vaults would be recreated whenever an account password was changed. Changing the master password would be a real pain in the butt. The only way for an attacker to crack the system is with a stolen client password (not present anywhere on the server) or by breaking a server-side client or master vault, all of which can be substantially hardened with high pbkdf2 iteration counts. An attacker could also break the system by subverting a client, stealth the client password by hook or by crook, taking over the server, forcing a database server restart, and jumping in from the compromised client. But at that point, you are so hopelessly compromised that nothing is going to work. Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files
On windows you can use DPAPI. I don't know if Linux (and other systems) has something similar (maybe Gnome-Keyring?). On the server you need to create an account used exclusively by the Firebird Service. Firebird can then use CryptProtectData() and CryptUnprotectData() to encrypt the database key and store the encrypted data in files (maybe hex/base64 encoded in database.conf). Working with keys in memory can be protected with CryptProtectMemory() and CryptUnprotectMemory(). It prevents others from viewing the key when the process is paged out to the swapfile. One important thing to remember is that if someone reset (not change) user's (firebird service account) password you will be unable to decrypt your data Brian Vraamark -Oprindelig meddelelse- Fra: Jim Starkey [mailto:j...@jimstarkey.net] Sendt: 22. august 2015 17:36 Til: For discussion among Firebird Developers Emne: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files Problem: How to start server on encrypted database files with a human to supply a password. Idea: Assume SRP is being used for authentication and that all (or most or some) are using long, randomly generated passwords from a client-side vault (or equivalent). This means that it is safe to store account/salt/verifier triplets in an unencrypted file external to the database (if you want to get fussy, hash the accounts). The server starts up unabled to access the database file. In this state, the first SRP connection request is processed through the external verifier file. After a secure connection is established with the client, the server requests that the client send a hash of the client's password that is used to open a server-side client specific vault containing the generated password for the master vault that contains the database file encryption key. The verifier file would be recreated by the server whenever a verifier changed. The account specific server-side vaults would be recreated whenever an account password was changed. Changing the master password would be a real pain in the butt. The only way for an attacker to crack the system is with a stolen client password (not present anywhere on the server) or by breaking a server-side client or master vault, all of which can be substantially hardened with high pbkdf2 iteration counts. An attacker could also break the system by subverting a client, stealth the client password by hook or by crook, taking over the server, forcing a database server restart, and jumping in from the compromised client. But at that point, you are so hopelessly compromised that nothing is going to work. Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Denne mail er blevet scannet for virus af TDC Mailfilter. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files
On Saturday, August 22, 2015, Brian Vraamark wrote: > On windows you can use DPAPI. I don't know if Linux (and other systems) > has something similar (maybe Gnome-Keyring?). > > I have a strong preference for portable, transparent solutions. In theory, Microsoft has the same problem that unattended startup without a remote connection has, which is everything Microsoft uses to decrypt private data is present on the local machine. Ultimately, Microsoft can only obscure it, which is why the recommended usage requires an external user dialog and password. There is also the small point that it has been broken (see Wikipedia). > On the server you need to create an account used exclusively by the > Firebird Service. Firebird can then use CryptProtectData() and > CryptUnprotectData() to encrypt the database key and store the encrypted > data in files (maybe hex/base64 encoded in database.conf). > > Working with keys in memory can be protected with CryptProtectMemory() and > CryptUnprotectMemory(). It prevents others from viewing the key when the > process is paged out to the swapfile. > > One important thing to remember is that if someone reset (not change) > user's (firebird service account) password you will be unable to decrypt > your data > > > Brian Vraamark > > > -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files
> I have a strong preference for portable, transparent solutions. That I can understand and would always be the best solution, but not always possible. > There is also the small point that it has been broken (see Wikipedia). As I read it, it was mostly before Windows XP. Since Windows Server 2003/Windows 7, a lot of changes in DPAPI has made it more secure. The security analysis from Passcape concludes: "DPAPI deserves such close attention at least for the fact that it's the only password-based system that provides appropriate and thoroughly thought out protection of user's personal data. None of the operating systems has a more viable alternative to DPAPI! We should, perhaps, mention that the first implementation of DPAPI had a number of serious flaws, which could enable a potential malefactor to easily compromise user's data protected by DPAPI. The first pancake is known to be always lumpy. In all the sequel operating systems, beginning with Windows XP, those vulnerabilities have not merely been eliminated; the entire DPAPI system has undergone a major revision. In particular, it has adopted new encryption algorithms; that has made the Master Key password lookup speed about 1000 (!) times slower. Master Key encryption errors that potentially allowed any user to gain access to any files encrypted by EFS were fixed. The local Master Key backup system has been replaced with the password reset disk, etc. Overall, the DPAPI encryption system has become more robust, powerful, meeting the stringent requirements of password security." Brian Vraamark -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files
One of the tenants of moderm cryptology is that algorithms and mechanisms have to be published for analysis and review. The basic idea is that security is based on a mathematical impossibility that a cryptosystem cabe be broken within the time remaining in the universe. The once dominant idea was that a system sufficiently obscure was good enough. I dare say that the experiece of the third reich demonstrated the weakness of the latter argument. Microsoft is assuming a position that is theoretically impossible and refuses to publish their system's algorithms for legititate analysis. It is hard to argue that their system is anything but garbage top to bottom, waiting only for a disgruntled employee to blw the whole thing sky high. It is well understood that security by obscurity is no security at all. If Microsoft actually believed they had a robus system, they wouldn't hesitate to publish -- and patent -- their system. Possibly it is fairly secure. More likely, it's bullshit. If they published the details, we would all know. But they won't. Once it was belived that nobody could get fired for going IBM (SNA anyone? Anyone?). Then it was Microsoft instead of IBM. But that was then abd this is now. Are you really going to trust a company that staked their future on Windiws RT tablets and Windows phones? To paraphrase Yoda, break me a frigging give. On Saturday, August 22, 2015, Brian Vraamark wrote: > > I have a strong preference for portable, transparent solutions. > > That I can understand and would always be the best solution, but not > always possible. > > > > There is also the small point that it has been broken (see Wikipedia). > > As I read it, it was mostly before Windows XP. Since Windows Server > 2003/Windows 7, a lot of changes in DPAPI has made it more secure. The > security analysis from Passcape concludes: > > "DPAPI deserves such close attention at least for the fact that it's the > only password-based system that provides appropriate and thoroughly thought > out protection of user's personal data. None of the operating systems has a > more viable alternative to DPAPI! > > We should, perhaps, mention that the first implementation of DPAPI had a > number of serious flaws, which could enable a potential malefactor to > easily compromise user's data protected by DPAPI. > > The first pancake is known to be always lumpy. In all the sequel operating > systems, beginning with Windows XP, those vulnerabilities have not merely > been eliminated; the entire DPAPI system has undergone a major revision. In > particular, it has adopted new encryption algorithms; that has made the > Master Key password lookup speed about 1000 (!) times slower. Master Key > encryption errors that potentially allowed any user to gain access to any > files encrypted by EFS were fixed. The local Master Key backup system has > been replaced with the password reset disk, etc. > > Overall, the DPAPI encryption system has become more robust, powerful, > meeting the stringent requirements of password security." > > > Brian Vraamark > > > -- > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files
James Starkey wrote: > Once it was belived that nobody could get fired for going IBM > (SNA anyone? Anyone?). I worked with SNA / SDLC for some years. I don't remember anyone getting fired for choosing it. -- Geoff Worboys Telesis Computing Pty Ltd -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
