Michael Graff wrote: > Storing the key at all where someone can get to is insecure. You > really need to question if you should store CC info at all. What > purpose do you need to store it for? If recurring charges, most > processing centers will allow you to schedule that sort of thing and > not have to store the CC info locally. If logging, can you perhaps > store only the last few digits of the card? > > If you are storing it "just in case" but don't expect to use it, I > would use a public key system, such as RSA. In RSA, you keep one of > the keys (the public one) on the server, and it encrypts data. To get > it out, you need the private key. People can hack away but so long as > they don't have the private key, they cannot read your data. (more > hand waving here, it IS possible, but we're entering into the world of > theoretical quantum computing here.) > > The numerous times I've had to handle CC data I was explicitly > forbidden to store the numbers (card, expiry date, or CCV) other than > the last 6 digits of the card. I could store anything returned from > the processor though, like auth numbers, status codes, etc. This was > in all our cases sufficient to reverse charges (if needed) or to bill > in a recurring manner. > > As for the examples, I think your "irb" is hiding data from you. Try > something like: > > x = AESCrypt.encrypt(...) > AESCrypt.decrypt(x, ...) > > I think your output is the same as mine, you just have ? marks where I > have some \301 escaped characters. > > --Michael
Hi, I wonder whether this was resolved. I'm having a similar issue. I encrypt using a Flash AES CTS cipher from the library (hurlant). I'm decrypting in Ruby. When used in Flash for both encrypt and decrypt, all is joyous. However, when I try to use the openSSL package within Ruby - the one mentioned above, I am able to decrypt most of the cipher text. However, the last 17 bytes are garbled. Lots of Google searching... This is a test system, and in it, I set the IV to 16 bytes of 0. (I really don't want to be yelled at here about the lack of security in such a scheme)... I get the same 'OpenSSL::CipherError: wrong final block length' error when calling the 'final' method. 'update' works like a charm. I see all of the clear test, in 32 byte chunks, up to the last partial block. Then, I see garbled data in the last partial. So, I'm guessing either the hurlant package handles the last partial differently than Ruby's openSSL, or (much much much more likely), I am doing something obviously wrong. Could a kind soul please let me know if they have experience and overcome such a problem? Thanks, Mike -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
