0

I want to ask you if there are (in practice) techniques for encoding a database in such a way, that table names are arbitrary and fields are encoded(not encrypted) in some way.

For example consider a class MVC in which model is devided in "low" and "high" level.The hight level communicates with the low level and the controller and the low level communicates with the high level and the DB.

The low level model knows about the DB structure and how it is encoded (and to translate between encoded structure and logical structure) and the high level knows only about DB logical structure.

Example: The actual DB contains table for users named "ff", which have fields "a"->for user id, "fdas"->for user name and "g12ds"->for password.

The hight level thinks that there is a table named "users", containing fields "uID", "uName", "uPass".

The low level knows about both and how to translate one to the other.

If the hight level wants to get a row where user name is "john1234", it asks the low level like $LOW->getRow("users.uName",EQUALS,"john1234"), then low level asks the db "select * from ff where fdas=='john1234'", translates the responce and returns to hight level a result like array("uName" => "john1234", "uID" => "75", "uPass" => "whatever")

The field values can also be encoded (like map 'a' to 'b', 'b' to 'c', '@' to 'g', 'g' to '+' and so on...) without affecting the search ability, as long as low-level model knows how to translate (and reverse the process).

The goal is to increase the security of the DB, for if an attacker gets to the data, he won't be able intuitively to tell in which table the users are stored and what are the user names.

My question is: is there an similar implementations in practice ?

tereško
  • 58,060
  • 25
  • 98
  • 150
user1328370
  • 401
  • 1
  • 3
  • 6
  • 1
    No, there is not a specific practice, which implements or recommends what you have described. But there is [Single Responsibility Principle](http://en.wikipedia.org/wiki/Single_responsibility_principle) as applied by use of [data mapper](http://martinfowler.com/eaaCatalog/dataMapper.html) pattern. Though I doubt that it's what you were looking for. – tereško Apr 24 '14 at 12:16
  • 2
    Security through obscurity is always a bad idea (tm); at one glance I can tell you what looks like a user name, email, first name, password, etc. It would make more sense to encrypt the field *values*. – Ja͢ck Apr 24 '14 at 12:22
  • Ok, but isn't it more difficult to say "kpjmqh,so;/vp, is a mail", rather than "john@gmail.com is a mail", thus it should make it just a little(not much) bit more secure, right? And aren't all the passwords, hashes, salts dependent on obscurity? Sure one can get the password just from it's hash by brute force, but that seems more difficult than just taking the unhashed pass, so hash should be more secure than plain-text passwords, shouldn't it? – user1328370 Apr 24 '14 at 12:42
  • I'm sorry - didn't understood the full meaning of the comment. And by encryption you mean some type of encoding(in order to pererve the ability to search the field), right? – user1328370 Apr 24 '14 at 12:57

0 Answers0