From: David W. Fenton on 9 Feb 2010 16:40 Salad <salad(a)oilandvinegar.com> wrote in news:wZCdndbzAZlVQe3WnZ2dnUVZ_u6dnZ2d(a)earthlink.com: > The way I look at is...I don't care much for the data. My concern > is my code and the manipulation of data. I'm exactly the opposite. The only security I care about is for the data. I don't care if anybody breaks into my code. They will be amazed at the beauty and cleverness of it and who would want to deny them that? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 9 Feb 2010 16:44 Banana <Banana(a)Republic.com> wrote in news:4B715B18.60500(a)Republic.com: > In the same thread, however, I've pointed out that accde seems to > be of limited use in context of web database because macros are > still editable. I've yet to find a way to use Sharepoint's > security upon those macros. I can deny the access to downloading > the file and offer only rich client database for download, which > is why I tend to agree with David that there's really not much new > security to Access. > > Data, OTOH, isn't even protected at all by mde/accde. It still can > be linked, queried, and modified. A necessary condition, I suppose > if one were to have legitimate need but there's just no way to > prevent illegimiate use short of moving the data out from Access > files into a server-based RDBMS (or Sharepoint as well) and thus > using their security mechanisms to manage the permissions to data > at object or even at row/column level. As I said, there is NO SECURITY in Access 2010 -- the claim of "enhanced security" is rubbish. You can't enhance what isn't there. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 9 Feb 2010 17:58 David W. Fenton wrote: > There is no way to use a database password to build a secure Access > application. The db password is not security at all. Just so you know - you're preaching to the choir here. But out of interest - what would you consider to be a properly secured file? If it's not encryption + password then what else can one do to the file so that it couldn't be used by unauthorized people? The real security comes in not having access to the data in first place, but that's where Access is basically screwed- it's a _file_-based database. The access is implied in its design. At least they made encryption + database password a single unit of operation in 2007 whereas in 2003 & earlier, you could specify a database password but the file would still be plaintext. Seriously lame. I'm still not clear whether 2007 uses the password as key and thus doesn't store the key on the file as was the case with encryption in 2003 & earlier. I'm led to believe that password is used as a key but would like something definite. Either way, both are/would a step in right direction, I'd think. But this won't change that all it mean is it takes more time to reach the data. (In case anyone doubts that one can crack 4096-bit RSA encryption in a timely manner- consider this: http://xkcd.com/538/ ) Anyway, I'm not sure what else you can do to secure a file to the point that unauthorized people can't access the file short of depending on external resources such as filesystem, OS, or daemon.
From: David W. Fenton on 10 Feb 2010 12:13 Banana <Banana(a)Republic.com> wrote in news:4B71E8A3.8040106(a)Republic.com: > David W. Fenton wrote: >> There is no way to use a database password to build a secure >> Access application. The db password is not security at all. > > Just so you know - you're preaching to the choir here. > > But out of interest - what would you consider to be a properly > secured file? If it's not encryption + password then what else can > one do to the file so that it couldn't be used by unauthorized > people? Jet ULS provides a proper system for securing the data and providing access control. MS could have enhanced its encryption (which was its main vulnerability, i.e., the passwords were inadequately encrypted). > The real security comes in not having access to the data in first > place, but that's where Access is basically screwed- it's a > _file_-based database. The access is implied in its design. I agree. And if you need that level of security you use a different database engine. But with the db password there is no way to secure your data, as the password will have to be embedded in your front end (either in the code or in the table links), and that means it's not really hidden at all, as anyone browsing the file with a hex editor can find the password (all constants and literals in VBA code are encoded literally, even in an MDE). Sure, you can encrypt your front end, but without a password on *that*, anybody can decrypt it and then you're back where you started. In other words, MS has replaced one ineffectual file-based security system with one that is EVEN LESS SECURE. > At least they made encryption + database password a single unit of > operation in 2007 whereas in 2003 & earlier, you could specify a > database password but the file would still be plaintext. Seriously > lame. To me, they are both lame. > I'm still not clear whether 2007 uses the password as key and thus > doesn't store the key on the file as was the case with encryption > in 2003 & earlier. I'm led to believe that password is used as a > key but would like something definite. Either way, both are/would > a step in right direction, I'd think. But this won't change that > all it mean is it takes more time to reach the data. I've been told that, contrary to my understanding, even with ACE the encryption key is stored in the header of the file. > Anyway, I'm not sure what else you can do to secure a file to the > point that unauthorized people can't access the file short of > depending on external resources such as filesystem, OS, or daemon. That's not the goal at all. By that argument, nobody would ever bother to install locks on the doors of their homes, since that won't stop the determined burglar. File-based security can never be as secure as server-based, but that's not something inherent to the methods of securing the data, but because of the access to the file that is required in that context. The reason SQL Server is more secure is because the demon controls access to the data, and access to the tools that control the demon are limited. Secondly, the MDF file for the database is not accessible, and the server is in a locked server room, and so forth. It's the same set of issues, but because the system has a single point of access (the demon) it's possible to make it more secure. But it's still vulnerable if anybody can get administrative control or if someone can get physical access to the server. It's orders of magnitude harder because of that, but it's still not completely invulnerable. I still think Jet ULS easily could have been improved with the same better encryption that the database password got in A2007. It would have still been crackable because the files are available, but it wouldn't have been nearly as easy as the old ULS. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 10 Feb 2010 13:21 David W. Fenton wrote: > Jet ULS provides a proper system for securing the data and providing > access control. MS could have enhanced its encryption (which was its > main vulnerability, i.e., the passwords were inadequately > encrypted). Ah. Your previous reply left me with the impression that even improved encryption would be useless but now I realize it's primarily the absence of access control is what make you perceive it as useless. Apologies. I have to agree that without access control, it's not terribly interesting, though I do think encrypting in tandem to specifying a password was a necessary precondition to proper security. The state of affair was worse in 2003 when you could create password but still have a plaintext file. That's like buying a shiny new lock but never installing it on the door. If ULS were to return, I would still expect that the file be encrypted when ULS was set up or even not require that the user need have full permissions on the file, thus enabling the option to manage permissions with filesystem permissions. > But with the db password there is no way to secure your data, as the > password will have to be embedded in your front end (either in the > code or in the table links), and that means it's not really hidden > at all, as anyone browsing the file with a hex editor can find the > password (all constants and literals in VBA code are encoded > literally, even in an MDE). Sure, you can encrypt your front end, > but without a password on *that*, anybody can decrypt it and then > you're back where you started. Just to point out that we face similar problem when we are using linked tables with server-based RDBMS that doesn't use Windows authentication. In one project, I solved this by doing this way: 1. Ask my user for a password. 2. Hash it quickly & discard the plaintext. 3. Select a salt. 4. Combine Salt & hash in some manner then re-hash. (I used SHA-256) 5. Send #4 in as the actual password granting them access to the backend. This way, I never need to save the password in the file, the user supply the piece but doesn't actually know the real password that was sent to the server. Salt are, for lack of better term, "deterministically randomly selected" so while they could read the salts in the MDE, they wouldn't know which salts was actually used, and even so, they don't actually know what algorithm I used to combine the salt & hash (which is also "deterministically randomly" selected as well) and MDE has compiled up the algorithms so they'll need to pull out a decompiler. Once authenticated, it was all up to the backend server's security mechanism to grant them the necessary permissions to the data as they work in the application. So, yes, the need to send password in is a serious problem but can be solved with careful application. I can only hope that Microsoft will fix this significant hole so it won't require considerable setup on the part of developer, especially one not practiced in field of security. I also imagine that for where it is not acceptable/desirable for user to enter in a password, the above wouldn't be acceptable, though it still can be solved by making use of API calls to interrogate the computer, windows user login, whatever and using this as a password, thus automating the #1. But that's still work on the developer when it should have been provided by Microsoft. The most ugliest but also most important fact about security is this: It's far easier to fool one into thinking it secured than to actually secure it. > I've been told that, contrary to my understanding, even with ACE the > encryption key is stored in the header of the file. I would expect that it'd store the hash... what else to compare the entered password with? But if the unhashed key is in fact stored in the header, then well... That's still lame. Still would like to get a definite answer on this.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Why couldn't exit the MS ACCESS program Next: Interacting with Website |