Is there a simple Encrypt/Decrypt UDF out there?
Paul Linehan
Hi all,
Is there a UDF library out there with two simple functions something
like this
String EncryptString(String);
String DecryptString(String);
It's to store passwords - it doesn't have to be NSA proof or anything,
but I'd just rather not store passwords unencrypted - even something as
unsophisticated as ROT13 would do it.
I have looked at the libs on Claudio Valderama's page, but I haven't
found anything there - or maybe I missed it?
I have asked about this on the C++ groups, but I'm not sure if I
wouldn't be better doing it on the DB server instead of in code?
Any thoughts, refs or URLs welcome.
TIA.
Paul...
--
plinehan__AT__yahoo__DOT__com
C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04
Michael Olschimke
> wouldn't be better doing it on the DB server instead of in code?
If you do it in your db, everyone can decrypt the stuff...they see your
source code. (except you use something like asymmetric encryption routines).
Do it in your app.
Michael
Paul Linehan
olsc...@gmx.net says...
Eh? You have a dll and you have an encryption routine in that - how
would anybody see it? Maybe they could see the BLR, but hey, anyone who
can read that deserves to get the data.
As I mentioned, it doesn't have to be NSA secure - just enough for
anybody who browses the db (e.g. with IBConsole) can see that we've made
an effort.
I remember once, I was playing with a programme that I was to be working
on - the *_first_* thing that I found was that passwords were stored as
ordinary text. Let me just say that it was an indication of the effort
that those who wrote it had made and this was reflected throughout the
app!
> Do it in your app.
Yep - I've done that - I'd just like to mess around with a UDF!
Paul...
> Michael
Craig Stuntz [TeamB]
> Is there a UDF library out there with two simple functions something
> like this
>
> String EncryptString(String);
> String DecryptString(String);
>
> It's to store passwords - it doesn't have to be NSA proof or
> anything, but I'd just rather not store passwords unencrypted - even
> something as unsophisticated as ROT13 would do it.
Never store passwords, even encrypted. Store a one-way hash of the
password + a salt. When you need to validate a password, add the salt
and then hash this value. If the hash result matches the stored value,
then you have a correct password. If not, the password is incorrect.
There is never a need to decrypt.
Note that this is even easier than encryption/decryption (since you
need only one function instead of two) and is considerably more secure.
Now, where to find a good hash function? Use Google. MD5 and SHA are
popular, strong, and free implementations are easy to find.
I don't know of any UDF libraries which implement these, but once you
have the algorithm itself, turning it into a UDF is trivial.
-Craig
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://delphi.weblogs.com
InterBase Perf. Monitor : http://delphi.weblogs.com/IBPerformanceMonitor
InterBase PLANalyzer 1.1: http://delphi.weblogs.com/IBPLANalyzer
Michael Olschimke
> would anybody see it? Maybe they could see the BLR, but hey, anyone who
> can read that deserves to get the data.
The problem is not the source of your dll, the problem are the calls to your
udf in your database source:
Encrypt('bla');
Decrypt(field);
If I want to get the password, i just call Decrypt with the encrypted pass
and voilá, it's done.
What I need is your udf and your db. Even If you delete the sp's source
text, I get the pass (via the blr or via my mind -> hmm...whats the reason
for the decrypt method? why is this password strings scrambled this way?
hmm..lets try to combine them....)
Thats the problem.
The only way to get around this is to use some asymetric encryption, but in
this case you have to provide the key to the database in any way, maybe to
an sp which does the encryption for you...
> As I mentioned, it doesn't have to be NSA secure - just enough for
> anybody who browses the db (e.g. with IBConsole) can see that we've made
> an effort.
Sure, but make an secure effort.
> I remember once, I was playing with a programme that I was to be working
> on - the *_first_* thing that I found was that passwords were stored as
> ordinary text. Let me just say that it was an indication of the effort
> that those who wrote it had made and this was reflected throughout the
> app!
Tools which store the passwords in plain texts are made by unreliable
programmers.
> > Do it in your app.
>
>
> Yep - I've done that - I'd just like to mess around with a UDF!
See above.
Michael
Craig Stuntz [TeamB]
> The only way to get around this is to use some asymetric encryption,
> but in this case you have to provide the key to the database in any
> way, maybe to an sp which does the encryption for you...
Not quite; one-way encryption (which is asymmetric in a very special
sort of way) will do the trick nicely with no key required.
Michael Olschimke
Michael
> Not quite; one-way encryption (which is asymmetric in a very special
> sort of way) will do the trick nicely with no key required.
1.1: http://delphi.weblogs.com/IBPLANalyzer
Michael Olschimke
"Michael Olschimke" <olsc...@gmx.net> wrote in message
news:3e96...@newsgroups.borland.com...
> okay, but how to decrypt that pw?
Okay, you wouldn't have to do it...if the encrypted stuff is the same as
encrypt('mypw'), the pw would be correct..but this only works, if no random
factor is part of the encryption process.
Michael
Craig Stuntz [TeamB]
> "Michael Olschimke" <olsc...@gmx.net> wrote in message
> news:3e96...@newsgroups.borland.com...
> > okay, but how to decrypt that pw?
This, of course, is the entire point.
>
> Okay, you wouldn't have to do it...if the encrypted stuff is the same
> as encrypt('mypw'), the pw would be correct..but this only works, if
> no random factor is part of the encryption process.
If a "random factor" is involved you're back to storing keys. If you
store them in the DB there's little point in encryption. :)
However, you should salt the password before hashing it -- this makes
dictionary attacks much harder. You can use something as simple as the
username as a salt, depending upon the strength you need.
Paul Linehan
cst...@vertexsoftware.com says...
> > It's to store passwords - it doesn't have to be NSA proof or
> > anything, but I'd just rather not store passwords unencrypted - even
> > something as unsophisticated as ROT13 would do it.
> Never store passwords, even encrypted.
I take your point, but, as I said, this is not going to be a major issue
- though mind you, the it becomes one (possible for an app that I'm
quoting for with medical data in it!), I will at least have learnt
something.
> Store a one-way hash of the password + a salt.
What's a salt? Is that like a key?
> When you need to validate a password, add the salt
> and then hash this value. If the hash result matches the stored value,
> then you have a correct password. If not, the password is incorrect.
> There is never a need to decrypt.
Yes, this was explained to me. One of those "smack forhead, "DOH""
moments.
> Note that this is even easier than encryption/decryption (since you
> need only one function instead of two) and is considerably more secure.
Agreed.
> Now, where to find a good hash function? Use Google. MD5 and SHA are
> popular, strong, and free implementations are easy to find.
I have tried, but nothing that I can find seems to have implemented them
in anything less that 500K of code that is all interdependent and comes
with about 4 gazillion other Encryption functions that I neither need
nor want - what I really want is just a function that I can just drop
into the Utils.cpp of my app.
I guess I'll just have to get down to the source!
I don't wish to appear lazy or ungrateful, it's just that the stuff I've
found so far is overkill to say the least - but I suppose it would be a
good learning experience.
> I don't know of any UDF libraries which implement these, but once you
> have the algorithm itself, turning it into a UDF is trivial.
Take it easy there! I've only just learned how to use UDFs that I can
download - I'll work on it though (after current project - real pressed
for time at the moment - meeting on Monday...)
Thanks for your input.
Paul...
> -Craig
Ivan Prenosil
> anybody who browses the db (e.g. with IBConsole) can see that we've made
> an effort.
Can't you just revoke select privileges for this data ?
Paul Linehan
pren...@ms.anet.cz says...
> > As I mentioned, it doesn't have to be NSA secure - just enough for
> > anybody who browses the db (e.g. with IBConsole) can see that we've made
> > an effort.
> Can't you just revoke select privileges for this data ?
No. Part of the conditions were that we provide a tool with access to
the raw data (they were burned before!). I'm giving him IBConsole, so,
no I can't hide the password data like that.
Mind you, it's only the manager of the organisation who will have that
tool, so it's not that important - I just want to be a *_little_*
professional in storing the passwords in an unreadable format - after
all, some people use the same password on many systems, and he has no
business knowing his employees' (plain text) passwords.
As I said, it doesn't have to be NSA secure, just illegible!
Paul...
> Ivan
Craig Stuntz [TeamB]
> > Store a one-way hash of the password + a salt.
>
> What's a salt? Is that like a key?
No, not at all. It's just some junk you stick onto the end of
whatever you're hashing.
If you just hashed the passwords, then someone can hash the dictionary
and compare and contrast. Start combining words, adding numbers, and
the rest and you can break most weak passwords.
If you hash the password+username, for example, then to do a
dictionary attack they have to do it separately for every user.
> > I don't know of any UDF libraries which implement these, but once
> > you have the algorithm itself, turning it into a UDF is trivial.
>
> Take it easy there! I've only just learned how to use UDFs that I can
> download - I'll work on it though (after current project - real
> pressed for time at the moment - meeting on Monday...)
Just look at some of the simpler UDFs in the FreeUDFLib. Once you see
how to accept a string and return another string, sticking in the code
to a different library to do the hash isn't a significant change.
Tom Olson
You might want to check out www.whamware.com. They have a product called
wiCrypt and a new product on the way called wiHash.
Tom
"Paul Linehan" <pa...@not.a.chance.ie> wrote in message
news:MPG.1900127a1...@newsgroups.borland.com...
Steve Weston
attempts at access security are of little real use or efficacy. They also
lull the user into a sense of security that isn't really there.
Sure, you can password protect access to the db via your app to the
database. But, Mr. Baddie can still access the db via any number of other
apps and utilities including IBConsole sitting right there in the IB
directory structure.
In the past, out of necessity, I not only hacked a pswd protected db, but
also hacked into its proprietary structure so that I could create a
conversion app for that data to my app. (Not bragging. It only took six
hours to devise the template.)
TurboPower had a product called LockBox that implemented many crypto schemes
in code and components. It's now "freeware" and available for C/Delphi
source download. Google or Vivisimo will find it.
If the user has ODBC and Excel then they can run any SQL against your db. If
IBConsole is there, it's even easier.
--
Steven S. Weston