I am trying to come up with an input mask to hide the first 12 digits of a
credit card number on a form, and to display the last 4.  I was using the
"Password" input mask, but then users have no idea which card was used (since
it masks everything).  Any suggestions?

Thanks!

Nick

Yes, do not use MS Access to store anything remotely sensitive such as CC
details, the security just isn't up to it.

Regards,
Keith.
www.keithwilby.com

Place an unbound control on your form and add code similar to the following
to the current event of your form:

Me.txtMaskedCCNo = "************" & Right(Me.CreditCardNo, 4)

WARNING: Storing Credit Card Numbers in an Access database is a very risky
thing to do. Access databases can be cracked fairly easily and you could be
setting  yourself up for serious legal problems if someone is able to
extract the credit card numbers of your customers.

Show quoteHide quote

Jumping in here (cos I can not see the OP's post):

OP, if you /do/ store CC numbers in an Access database, you should
encrypt them using a suitable cipher. Then, if someone cracks the
database security, they will only get the encrypted CC numbers, not the
actual ones.

As the others have said, you are truly asking for trouble if you store
unencrypted CC numbers in an Access database.

HTH,
TC

I've already used the Tools>Security> Encrypt/Decrypt Database tool to
encrypt the file.  However, is there a better way of doing this?  IE,
encrypting/decrypting functions in VB Script, so the tables store encrypted
data?

Also, while we're on that topic, are there any hash functions or modules
that I can use, such as MD5 or SHA-1?

Thanks!

Nick

Show quoteHide quote

Encrypting the database (using Access encryption) is absolutely
definitely completely and positively not even *nearly* enough. Googling
this group for that topic, will easily tell you why.

Hash functions such as MD5 and SHA-1 are not what you want. Those are
/one way/ functions - you can't encrypt /and decrypt/ with them.

Seriously, you should not be storing CC numbers in an Access database
with your current level of knowledge of the issues involved. Not trying
to be rude - just stating the facts. I strongly recommend that you read
up on cryptography first, then maybe ask some questions in sci.crypt,
for example. Or get some advice from a qualified cryptographer before
you continue. Believe me, cryptography is /hard/ - there's just no way
that an amateur will get it right, there are just too many fatal,
hard-to-understand traps.

Cheers,
TC

Hmm, having got all that off my chest ...

You'd probably want a symmetric block cipher such as AES. Make sure
your key is constructed at runtime:  chr$(41) & chr$(42) ..., not
defined verbatim in the code ("AB..."). Make your database an MDE, so
no-one alse can look at the code. Check with sci.crypt that AES in
ECB(?) mode would be appropriate - or google sci.crypt for CC or
"credit card" - it's probably been discussed before.

I am an /amateur/ cryptographer: treat all this accordingly!

HTH,
TC

TC,

You are absolutely correct.  I wish I knew more about all of this security
hollabaloo, so I would be better suited for this job.  Haha, and I could quit
asking so many dumb questions on these forums.  Hmm... I guess that if I
hadn't gotten my sorry ass kicked out of the Air Force Academy, I'd be a
semester and a half away from my Comp Sci degree by now.  Not to mention, I'd
probably be taking Cryptography at this very moment.  :-p  lol, it's almost
ironic...

Enough reminiscing though.  I know that I don't know nearly enough about
Access security and cryptography - I'm a noob in this department.  But it's
still my job to build this database, so I'd better start learning about it
from the people who know more than I do.

AES?  Sounds good - I'll see if I can look it up.  Though I'm curious about
your key construction comment.  If I'm distributing MDEs anyway, isn't it a
bit redundant to contstruct the key with chr$(i)s?  Or is that just common
practice for putting keys in code?  Because if someone is trying to hack the
database and somehow gets a hold of the code... well, I just don't understand
how someone would go about hacking an Access MDE to begin with.  Maybe that
deserves a thread... lol, though I should probably be circumspect about
starting a "How do I Hack Access MDEs" thread.

Anywho, thank you for the info TC.  I mean it.  I'll be sure to look up AES
and any similar encryption/decryption thingamajigs.  If you have any other
suggestions at all that could help, please let me know!

Thanks!

Nick

Ah.  And... I know MD5 and SHA-1 are one-way hash functions.  I brought it
up because I was trying to find hash functions for a separate issue.  Though
I think I don't want to deal with the complexity of custom access security
just yet.  Maybe later.

Show quoteHide quote

Hi Nick

Tatakau wrote:
There are no dumb questions when it comes to security :-)


AES is the new US encryption standard. The previous one was DES. Both
of them are publically available in various languages including VB
(which is very close to VBA).

Both those ciphers are so-called block ciphers - not stream ciphers.
Stream ciphers suffer from a devastating attack (called the "known
plaintext attack") if you encrypt /several different messages/ (eg. CC
numbers) with the /same key/. You would avoid that attack by using a
different key to encrypt each CC number, or, by using a block cipher
instead. That's why I suggested AES - a block cipher. RC4 is a commonly
used stream cipher. So you would absolutely not want to encrypt several
CC numbers with the /same key/, if you were using RC4.


I suggested that because I'm not sure whether strings like "ABCDE" are
stored verbatim in an MDE, or not. I suspect that they are. Say you
were using DES to encrypt the CC numbers. DES takes a 56-bit (7 byte
key). The attacker could just take each consecutive 7 bytes from your
MDE file, & try that as the key. If the key /is/ stored verbatim, that
attack would find it instantly; oops! So I always feel it is safer to
construct the key at runtime.

Another problem with MDEs, is this. An access database (mdb or mde)
contains a significant amount of uninitialized space within the file.
That space is used for buffers etc. at runtime. When Access creates the
mdb or mde file & saves it to disk, that space in the file is filled
with whatever is in memory at that time. >>> I have seen an MDE file
which contained, in that unused space of the file, some *source code*
from the VBA modules in that database <<< !!  So in theory, part of
your sourcecode (containing the key generation expression) might
possibly exist in the file!  There is no standard way around this rare,
but possible, problem. Access should, but doesn't, zero-out the unused
portions of the file, before it stores it on disk.


Remember that with CC numbers, you are primarily concerned with /data/
security. The MDE is for /code/ security. You could have an unsecured
MDE, in which case, your code is safe, but your data is open for all to
see.

When you decide how to proceed, I seriously suggest that you ask some
questions in sci.crypt. But be careful to do some research first. Also,
when you ask a question there, be sure to say what kind & level of
threats you need to defend against. Security means nothing, in the
absence of a definition of what threats you need to defend against. For
example, is my front door lock secure enough? YES to defend against a
passer by, MAYBE to defend against a burglar, NO to defend against a
locksmith or the CIA!

Hope this all helps,

Cheers,
TC

Security without signon
Creating a secure database on a network
Basing Object Permissions on Ownership
Access Tools Menu Disabled
Creating user-level security with MS Access file on a network
Access security best practice - Stupid question(s) #2
Access Security
Invalid page fault in module RPCRT4.dll
Prompting Users for a new password
Adobe 7.0 and Office Access 2003