Garbled credit card numbers? BUG??
Locked
Garbled credit card numbers? BUG??
 
|
This post was updated on .
Hi,
Does createCreditCard service store Credit Card Number in the CREDIT_CARD table as some kind of encoded or garbled text or stores it in clear? I see the values encoded but looked at the service code and it doesnt seem like it is encoded. Thanks |
|
|
did a search through google
ofbiz credit card entity encrypt here is a link http://lists.ofbiz.org/pipermail/dev/2004-September/006391.html Ritz123 sent the following on 5/29/2008 5:43 PM: > Hi, > > Does createCreditCard service store Credit Card Number in the CREDIT_CARD > table as some kind of encoded or garbled text or stores it in clear? > > I see the values encoded but looked at the service code and it doesnt seem > like it is encoded. > > Thanks |
Re: Garbled credit card numbers? - BUG
|
|
Thanks BJ for the pointer. I guess from next time onwards, I will search the dev list too.
But seems like there is a bug or atleast the functionality is not fully coded. When you use tables with encrypted fields in view entity - the fields are NOT decoded. They are decoded only if you do a findBy on that entity directly or atleast that is what I am seeing happening at runtime and looking at the code. May be an Ofbiz commiter can confirm.
|
Re: Garbled credit card numbers? - BUG
|
|
I may be off on this, but my understanding is you can not decode
encrypted fields. you have to encrypt the new data then compare the encryption data against each other. Ritz123 sent the following on 5/30/2008 9:29 AM: > Thanks BJ for the pointer. I guess from next time onwards, I will search the > dev list too. > > But seems like there is a bug or atleast the functionality is not fully > coded. When you use tables with encrypted fields in view entity - the fields > are NOT decoded. They are decoded only if you do a findBy on that entity > directly or atleast that is what I am seeing happening at runtime and > looking at the code. > > May be an Ofbiz commiter can confirm. > > > BJ Freeman wrote: >> did a search through google >> ofbiz credit card entity encrypt >> here is a link >> http://lists.ofbiz.org/pipermail/dev/2004-September/006391.html >> >> >> Ritz123 sent the following on 5/29/2008 5:43 PM: >>> Hi, >>> >>> Does createCreditCard service store Credit Card Number in the CREDIT_CARD >>> table as some kind of encoded or garbled text or stores it in clear? >>> >>> I see the values encoded but looked at the service code and it doesnt >>> seem >>> like it is encoded. >>> >>> Thanks >> >> > |
Re: Garbled credit card numbers? - BUG
|
|
The thread you pointed me to mentions they are automatically and transparently decrypted at runtime and I looked into the code to confirm, it is indeed getting decrypted at runtime by findBy* methods by checking if field.getEncrypt() == true.
Also if you want to display the credit card number back to the user (editcreditcard.ftl does that) in order for them to modify or for whatever other reasons, one needs decrypted field. Its another story that editcreditcard.ftl and related code replaces all but last 4 digits with * for security, but the # of digits (chars) returned will depend on the type of card used. Encrypted chars are longer than the original cc #.
|
Re: Garbled credit card numbers? - BUG
|
|
In reply to this post by BJ Freeman
Only passwords are one-way encrypted, ie for comparison only purposes. Credit card numbers and other such fields must be decrypted otherwise they are of no value as the user would have to enter their credit card number each time, and the system could not do things such as automatically retrying card transactions. -David On May 30, 2008, at 11:45 AM, BJ Freeman wrote: > I may be off on this, but my understanding is you can not decode > encrypted fields. you have to encrypt the new data then compare the > encryption data against each other. > > Ritz123 sent the following on 5/30/2008 9:29 AM: >> Thanks BJ for the pointer. I guess from next time onwards, I will >> search the >> dev list too. >> >> But seems like there is a bug or atleast the functionality is not >> fully >> coded. When you use tables with encrypted fields in view entity - >> the fields >> are NOT decoded. They are decoded only if you do a findBy on that >> entity >> directly or atleast that is what I am seeing happening at runtime and >> looking at the code. >> >> May be an Ofbiz commiter can confirm. >> >> >> BJ Freeman wrote: >>> did a search through google >>> ofbiz credit card entity encrypt >>> here is a link >>> http://lists.ofbiz.org/pipermail/dev/2004-September/006391.html >>> >>> >>> Ritz123 sent the following on 5/29/2008 5:43 PM: >>>> Hi, >>>> >>>> Does createCreditCard service store Credit Card Number in the >>>> CREDIT_CARD >>>> table as some kind of encoded or garbled text or stores it in >>>> clear? >>>> >>>> I see the values encoded but looked at the service code and it >>>> doesnt >>>> seem >>>> like it is encoded. >>>> >>>> Thanks >>> >>> >> > |
Re: Garbled credit card numbers? - BUG
|
|
In reply to this post by Ritesh Trivedi
Thank you for reporting this and looking into it Ritesh. A fix is committed in SVN rev 662090. The testing I did was somewhat minimal, just viewing the entity PaymentMethodAndCreditCard through the WebTools Entity Data Maintenance screens. The credit card number now comes through properly there instead of the encoded String. -David On May 30, 2008, at 11:56 AM, Ritz123 wrote: > > The thread you pointed me to mentions they are automatically and > transparently decrypted at runtime and I looked into the code to > confirm, > it is indeed getting decrypted at runtime by findBy* methods by > checking if > field.getEncrypt() == true. > > Also if you want to display the credit card number back to the user > (editcreditcard.ftl does that) in order for them to modify or for > whatever > other reasons, one needs decrypted field. Its another story that > editcreditcard.ftl and related code replaces all but last 4 digits > with * > for security, but the # of digits (chars) returned will depend on > the type > of card used. Encrypted chars are longer than the original cc #. > > > BJ Freeman wrote: >> >> I may be off on this, but my understanding is you can not decode >> encrypted fields. you have to encrypt the new data then compare the >> encryption data against each other. >> >> Ritz123 sent the following on 5/30/2008 9:29 AM: >>> Thanks BJ for the pointer. I guess from next time onwards, I will >>> search >>> the >>> dev list too. >>> >>> But seems like there is a bug or atleast the functionality is not >>> fully >>> coded. When you use tables with encrypted fields in view entity - >>> the >>> fields >>> are NOT decoded. They are decoded only if you do a findBy on that >>> entity >>> directly or atleast that is what I am seeing happening at runtime >>> and >>> looking at the code. >>> >>> May be an Ofbiz commiter can confirm. >>> >>> >>> BJ Freeman wrote: >>>> did a search through google >>>> ofbiz credit card entity encrypt >>>> here is a link >>>> http://lists.ofbiz.org/pipermail/dev/2004-September/006391.html >>>> >>>> >>>> Ritz123 sent the following on 5/29/2008 5:43 PM: >>>>> Hi, >>>>> >>>>> Does createCreditCard service store Credit Card Number in the >>>>> CREDIT_CARD >>>>> table as some kind of encoded or garbled text or stores it in >>>>> clear? >>>>> >>>>> I see the values encoded but looked at the service code and it >>>>> doesnt >>>>> seem >>>>> like it is encoded. >>>>> >>>>> Thanks >>>> >>>> >>> >> >> >> > > -- > View this message in context: http://www.nabble.com/Garbled-credit-card-numbers--BUG---tp17549189p17564823.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > |
Re: Garbled credit card numbers? - BUG
|
|
Thanks David for fixing it (and so quickly), I will try the latest out and let you know if there is any issue.
|
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |