![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 11 to 20 of 43 total |
![]() |
Sun, Aug 21 2016 6:59 PM | Permanent Link |
Steve Gill | I'm going to use an external module for writing/reading an encrypted user update file, which is called by a job.
= Steve |
Mon, Aug 22 2016 4:23 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Steve
I'd either do that or add the password to your user table making sure it was encrypted Roy Lambert |
Thu, Aug 25 2016 5:58 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> I was loath to suggest anything like that because I don't know a way > to export a table in an encrypted fashion so the passwords are there > in the clear. Ummm, do I read that as EWB is storing passwords as-is? That's a no-no in this modern era. I hope that Tim has converting to salt and SHA256 hash on the early to-do list. (Probably with a "mode" column to allow conversion from old to new and allow future adaptations to new algorithms). -- Matthew Jones |
Thu, Aug 25 2016 7:15 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
>Ummm, do I read that as EWB is storing passwords as-is? That's a no-no >in this modern era. I hope that Tim has converting to salt and SHA256 >hash on the early to-do list. (Probably with a "mode" column to allow >conversion from old to new and allow future adaptations to new >algorithms). Did you get confused about which forum this was ![]() ElevateDB, as far as I know, stores user details in the configuration file which is encrypted on disk. You can ask for specific tables to be encrypted and BACKUP respects the encryption (which means it can't compress data as well as I'd like). My response was in respect of EXPORTing tables and that's done in the clear - makes sense otherwise you'd not be able to use them elsewhere. I have no idea what EWB does but I suspect its a bit like with EDBManager's and edbsrvr's ini files - your responsibility. Roy Lambert |
Thu, Aug 25 2016 7:35 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> My response was in respect of EXPORTing tables and that's done in > the clear - makes sense otherwise you'd not be able to use them > elsewhere. I got the right forum, wrong name. No password database should be exportable in the clear in 2016. Unless you are a bank with big security apparatus in place, and even then it isn't necessary. The key is that you should hash the password with salt, and store those two. You can move them both to use them elsewhere. As I say, it is typical to have a "mode" column too so that you can tell what to do with them, so you might have mode 1 as "plain stored password" and mode 2 as "hash256withSalt". And then mode 3 as "fixedHash256" or something. To be able to get a plain text password version at all is a security risk, particularly for the database admin password when the decryption key will be sitting on disk with it... (The risk may be low, but it is there nowadays, so it is worth solving. I do these things so I can say I was using best practice for when something gets hacked...) -- Matthew Jones |
Thu, Aug 25 2016 8:10 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
>I got the right forum, wrong name. My brain's going like that as well <vbg> >No password database should be >exportable in the clear in 2016. I disagree with this. More from a view of its my data and I'll do what I want with it than from a security viewpoint. Being fair and sensible. ElevateDB has enough security in place that if you reach a point where its possible to export the users table with passwords its already to late to worry. A pencil, paper and enough time to write will do the job. If the programmer chooses to build a feature in to do that for any old user (note STeve hasn't) then that's his problem not the databases. >Unless you are a bank with big >security apparatus in place, and even then it isn't necessary. That statement makes my mouth taste bad. Mixing banks and security in one sentence is just plain wrong. Remember these are the organisations that are so good at security that literally billions of pounds can be stolen before they notice (SWIFT anyone), if they do; who don't have a mechanism to tell if the ATMs have been tampered with. >The key >is that you should hash the password with salt, and store those two. >You can move them both to use them elsewhere. As I say, it is typical >to have a "mode" column too so that you can tell what to do with them, >so you might have mode 1 as "plain stored password" and mode 2 as >"hash256withSalt". And then mode 3 as "fixedHash256" or something. > >To be able to get a plain text password version at all is a security >risk, particularly for the database admin password when the decryption >key will be sitting on disk with it... To create a new user, or maintain a users password, which is what this was required for requires the password to be in the clear at the point the user is created or the password modified. Whatever you do that is inescapable unless Tim changes how ElevateDB works. You are therefore guaranteed to have something sitting on disk, at multiple locations, to decrypt the password however stored. OK I can come up with alternative stratagems but they would require me to build my own password management system. >(The risk may be low, but it is there nowadays, so it is worth solving. >I do these things so I can say I was using best practice for when >something gets hacked...) The bit you seem to be missing is "proportionality". Yes I want my on-line banking secure (but I'm still not installing Rapport) but I don't care about my free subscription to The Register. Sorry you hit my rant button. I've got it under control now. Roy |
Thu, Aug 25 2016 9:51 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> To create a new user, or maintain a users password, which is what > this was required for requires the password to be in the clear at the > point the user is created or the password modified. Whatever you do > that is inescapable unless Tim changes how ElevateDB works. You are > therefore guaranteed to have something sitting on disk, at multiple > locations, to decrypt the password however stored. Sorry, but this is wrong. The password should never be stored as-is. The key is that to log in, you send the password and that is combined with the salt on disk, and you see if the hash matches. If so, you are authenticated. The key therefore is that with the many passwords you have, none are ever stored, and thus to attack the system you have to have a long term monitor. Most attacks though get access to the computer remotely, and dump the database tables. To have plain text passwords in that data is not good. Nowadays, it is irresponsible programming. Yes, I have a pet rant on this, but then I see how many stupid mistakes are still made on security. Now, how you choose to organise your database and tables is up to you - I don't care if you store the passwords in all caps and show them on the main screen of your application. But I depend on the EDB security for my web shop, and to have a way for someone to get a dump of the administrator password in plain text is not something I like the sound of. My code is such that the application uses a restricted rights user, and the admin password is never stored on the server. Despite the encryption in the EDB code, it should not be stored in plain text. It's not hard to fix and do properly. To go back to the bank reference, it is like me keeping my PIN secure, and then finding the cash is all sitting behind the tellers in big piles, not held in a safe. 8-) Anyway, enough said, this isn't a major flaw, just something that would be good to have tidied up. -- Matthew Jones |
Thu, Aug 25 2016 10:43 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
>> To create a new user, or maintain a users password, which is what >> this was required for requires the password to be in the clear at the >> point the user is created or the password modified. Whatever you do >> that is inescapable unless Tim changes how ElevateDB works. You are >> therefore guaranteed to have something sitting on disk, at multiple >> locations, to decrypt the password however stored. > >Sorry, but this is wrong. You may disagree with the approach but its factually correct (or at least until I'm corrected by Tim I believe it is) >The password should never be stored as-is. >The key is that to log in, you send the password and that is combined >with the salt on disk, and you see if the hash matches. If so, you are >authenticated. The key therefore is that with the many passwords you >have, none are ever stored, and thus to attack the system you have to >have a long term monitor. Most attacks though get access to the >computer remotely, and dump the database tables. To have plain text >passwords in that data is not good. Nowadays, it is irresponsible >programming. Yes, I have a pet rant on this, but then I see how many >stupid mistakes are still made on security. I don't disagree for anything requiring a high level of security. I do agree with you - most of the password dumps I've read about come from SQL injection. >Now, how you choose to organise your database and tables is up to you - >I don't care if you store the passwords in all caps and show them on >the main screen of your application. But I depend on the EDB security >for my web shop, and to have a way for someone to get a dump of the >administrator password in plain text is not something I like the sound >of. My code is such that the application uses a restricted rights user, >and the admin password is never stored on the server. Despite the >encryption in the EDB code, it should not be stored in plain text. It's >not hard to fix and do properly. I think I'm confused now. Only allowing users restricted access prevents them from exporting the users table. I've just checked the contents of the edbsrvr.ini and that has the encryption password and engine signature but no user information so unless you allow then to enter free form SQL of add a menu option to export the users file I don't see how they can get at the password. >To go back to the bank reference, it is like me keeping my PIN secure, >and then finding the cash is all sitting behind the tellers in big >piles, not held in a safe. 8-) I don't mind that. Unless they can link my PIN to the big pile of cash and its disapearing I'm OKish (interest rates wil go up to pay for their carelessness). However, just to make the analogy a bit sillier - don't forget some crooks yoicked the ATM out of the wall and drove off with it ![]() You've obviously researched this so maybe you can answer something that baffles me. RBS use a triple "password" system - first is customer number, then three from a four character pin then 3 from a longer password (can't remember the maximum size). Every so often I try and figure out how they do that without having the pin and password in a decrypted for to check against. And fail. Do you have any idea? Roy |
Thu, Aug 25 2016 11:06 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> Matthew > > > >> To create a new user, or maintain a users password, which is what > >> this was required for requires the password to be in the clear at > the >> point the user is created or the password modified. Whatever > you do >> that is inescapable unless Tim changes how ElevateDB works. > You are >> therefore guaranteed to have something sitting on disk, at > multiple >> locations, to decrypt the password however stored. > > > > Sorry, but this is wrong. > > You may disagree with the approach but its factually correct (or at > least until I'm corrected by Tim I believe it is) Okay, to be clear, yes, the password is needed for creating and maintaining a user's password. But it can be stored as a hash immediately. The wrong part is that it is ever stored. > I don't disagree for anything requiring a high level of security. I > do agree with you - most of the password dumps I've read about come > from SQL injection. And the key is, EDB doesn't know how much security any customer needs, so should assume the best practice is needed. You don't care how it is done, and it makes no difference to the interface. > I think I'm confused now. Only allowing users restricted access > prevents them from exporting the users table. I've just checked the > contents of the edbsrvr.ini and that has the encryption password and > engine signature but no user information so unless you allow then to > enter free form SQL of add a menu option to export the users file I > don't see how they can get at the password. The key here is weakness. As with most security implementations, the design is usually good, and the implementation is where the problems occur. Things like the SSL loopholes, where you could work things out. EDB source is "freely available" to anyone who cares. The signatures are there on the disk in your application, so I can decrypt the data and work it all out. This is not about legitimate users getting access, it is about illegitimate users. And indeed, someone who can see those transfer files, and see the plain text passwords going by. They are immediately usable. A salt and hash are much harder to use. To be clear, I have seen far far worse than this. EDB is fantastic compared to some things. I'd just like to see this moved to best practice. > > To go back to the bank reference, it is like me keeping my PIN > > secure, and then finding the cash is all sitting behind the tellers > > in big piles, not held in a safe. 8-) > > I don't mind that. Unless they can link my PIN to the big pile of > cash and its disapearing I'm OKish (interest rates wil go up to pay > for their carelessness). However, just to make the analogy a bit > sillier - don't forget some crooks yoicked the ATM out of the wall > and drove off with it ![]() Yep, you are right. But as a developer, I don't want to be the one having to explain my choice. If someone hacks the system and works out hash matches, at least I was using tools using the best practice. And for completeness, I checked the PCI requirements. They just require all passwords to be encrypted in transit and storage. Which EDB does, so long as you don't do this export for transfer thing of course, at which point PCI fail. > > You've obviously researched this so maybe you can answer something > that baffles me. RBS use a triple "password" system - first is > customer number, then three from a four character pin then 3 from a > longer password (can't remember the maximum size). Every so often I > try and figure out how they do that without having the pin and > password in a decrypted for to check against. And fail. Do you have > any idea? I participated in a big discussion on this once. I can work out many ways to implement it in a proper clean modern way (for example, you take the memorable word, make 20 combinations of the letters, hash each one, then pick one of the combinations at check time), but mainly they have separate hardware in secure locations to store them. They have the money to "do it properly" with people in charge of the interfaces to particular data and thus you can't get the data from outside, only check against it. Most organisations don't have such control complexity as an option. -- Matthew Jones |
Thu, Aug 25 2016 11:50 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
>And the key is, EDB doesn't know how much security any customer needs, >so should assume the best practice is needed. You don't care how it is >done, and it makes no difference to the interface. It would be a good change but I wonder what the impact on current users would be if Tim made that sort of change? >The signatures >are there on the disk in your application Yes and no - the encryption key is in there but obfusticated in a nice difficult to find way, the engine signature isn't. As long as I stick to file/server the combination of engine signature/table encryption/user passwords/ no direct user SQL input makes it fairly secure. Once moved to client/server and the standard ini file which holds the engine signature/table encryption key it isn't. >And indeed, someone who can see those >transfer files, and see the plain text passwords going by. They are >immediately usable. A salt and hash are much harder to use. That was my concern with transmitting them around in the clear. >To be clear, I have seen far far worse than this. EDB is fantastic >compared to some things. You should see some of my early stuff to to make it look even better! >make 20 combinations of the letters, hash each >one, then pick one of the combinations at check time), I hadn't thought of making limited sets - I always thought in terms or random(length(password)) Your approach would make it sane. Roy Lambert |
« Previous Page | Page 2 of 5 | Next Page » |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Saturday, June 22, 2024 at 05:51 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |