Re^4: Encrypting strings with more than 8 bytes.

No, Crypt::CreditCard uses AES, which is a symmetric cipher. But it cleverly uses the user password as part of the encryption process (and ideally that password should not be available to the system unless the user is logged on), so it's a good method to use when you need access to the credit card number from the website with user interaction.

Still, given that it's marked as non-production I would say Andre should not use it unless he's not intending his system to go into production.

There are ten types of people: those that understand binary and those that don't.

Comment on Re^4: Encrypting strings with more than 8 bytes. Download Code

Replies are listed 'Best First'.
Re^5: Encrypting strings with more than 8 bytes. by diotalevi (Canon) on Jan 13, 2006 at 16:40 UTC
Lots of CPAN authors are too cautious with their warnings about "Oooh! Not for production!" I don't always believe them. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^6: Encrypting strings with more than 8 bytes. by tirwhan (Abbot) on Jan 13, 2006 at 17:02 UTC
Hrmph. Well I guess you don't complain when such a module blows up in your face either? This is really a strange issue, on the one hand people complain that there's no quality control on CPAN and there's lots of crap floating about. On the one hand users will just cheerfully ignore strong warnings by module authors (who after all should know best how production-ready their modules are), blithely use unsuitable code and recommend this usage to others. Just because you're given the rope doesn't mean you should hang yourself. In this particular case we're talking about a security measure designed to protect a pretty sensitive piece of data. If somebody happens to steal this data and use it for nefarious porpoises and the clients (or their attorneys) then ask the site owner how he secured it, it isn't going to look too great if he answers "I used this alpha software, the author recommended I shouldn't use it, but I didn't believe him", is it? I'm not saying such a warning should always prevent usage of a module in every case. If you've looked at the module in detail, analysed the code and found it matching your own standards then more power to you. But it doesn't sound like either you or I have done that, and recommending a development release for a security-critical application without such an analysis seems a trifle daring, don't you think? There are ten types of people: those that understand binary and those that don't.	[reply] [d/l]
A reply falls below the community's threshold of quality. You may see it by logging in.