Son zamanlarda bir sorun TripleDESgereken standardını kullanarak, bir belirteç olarak kullanılmak üzere şifreli bir dize talep edildi ödeme işlemci ile bir API çengel ile ilgili ortaya çıktı. Bizim Başvurular kakmak etiketi ColdFusion kullanılarak çalıştırılması - TripleDESGiriş desteklediğini - biz geri elde edemiyorlardı sonuç ödeme işlemci beklediğim değildi ancak.
Her şeyden önce, burada ödeme işlemci bekliyorduk çıkan token.
AYOF+kRtg239Mnyc8QIarw==
Ve aşağıda kullandığımız ColdFusion pasajı ve sonuçta dizedir.
<!--- Coldfusion Crypt (here be monsters) --->
<cfset theKey="123412341234123412341234">
<cfset theString = "username=test123">
<cfset strEncodedEnc = Encrypt(theString, theKey, "DESEDE", "Base64")>
<!---
resulting string(strEncodedEnc): tc/Jb7E9w+HpU2Yvn5dA7ILGmyNTQM0h
--->
Gördüğünüz gibi, bu bizim için umut vardı dize dönen değildi. Bir çözüm arayan, bu süreç için ColdFusion hendeğe ve PHP belirteci yeniden çalıştı.
Şimdi çeşitli dillerde farklı şekillerde şifreleme uygulamak farkında değilim - örneğin bir C # uygulama ve PHP arka uç arasındaki geçmiş yönetiminde şifreleme, ben iki konuşmak almak için dolgu ile ilgili oynamak zorunda kaldı, ama var benim deneyim şifreleme standartlarına geldiğinde PHP genellikle davrandığını olmuştur.
Neyse, biz denedik PHP kaynağı ve elde edilen dize üzerinde.
/* PHP Circus (here be Elephants) */
$theKey="123412341234123412341234";
$theString="username=test123";
$strEncodedEnc=base64_encode(mcrypt_ecb (MCRYPT_3DES, $theKey, $theString, MCRYPT_ENCRYPT));
/*
resulting string(strEncodedEnc): sfiSu4mVggia8Ysw98x0uw==
*/
Size açıkça görebileceğiniz gibi, biz ödeme işlemcisi tarafından beklenen dize VE ColdFusion tarafından üretilen bir iki farklı başka bir dize var. Cue kafa karşı duvara entegrasyon teknikleri.
Ödeme işlemci (çok ve 'biz, sorunları kodlama, yanlış yapıyor olması gerekir yardım kılavuzu okuyamıyorum' belirten tekrar sürü) nihayet daha fazla olan birine tırmandı edildi ile birçok ileri-geri iletişim Sonrası geri adım başardı ve aslında bakmak ve sorunu teşhis birlikte ovmak beyin hücrelerinin bir çift.
O bizim CF ve PHP girişimleri doğru dize sonuçlanan değil, kabul etti. Hızlı bir aramadan sonra, o da neccesarily bizim kaynak olmadığını kabul etti, ama yerine iki dil TripleDESgereken standardın kendi vizyonunu hayata nasıl.
Bu sabah ofise geliyor, biz Perl, kaynak kod parçası ile bir e-posta ile karşılandı. Bu doğrudan beklenen belirteci üretmek için kendi ucunda kullandığınız kod oldu edilir.
#!/usr/bin/perl
# Perl Crypt Calamity (here be...something)
use strict;
use CGI;
use MIME::Base64;
use Crypt::TripleDES;
my $cgi = CGI->new();
my $param = $cgi->Vars();
$param->{key} = "123412341234123412341234";
$param->{string} = "username=test123";
my $des = Crypt::TripleDES->new();
my $enc = $des->encrypt3($param->{string}, $param->{key});
$enc = encode_base64($enc);
$enc =~ s/\n//gs;
# resulting string (enc): AYOF+kRtg239Mnyc8QIarw==
Yani, biz var. Üç dil, onlar TripleDESgereken Standart Şifreleme gibi belgelerde alıntı ne üç uygulamaları ve üç tamamen farklı sonuçta elde edilen dizeler.
Benim sorum bu üç dil ve TripleDESgereken algoritma kendi uygulamalarında sizin deneyim, size aynı cevabı vermek için bunlardan herhangi ikisini almak mümkün olmuştur ve bu yüzden ne kodu tweaks sırayla yapmak zorunda olmasaydı Sonuç gelmek için?
Bu çok süzgün bir soru anlıyorum, ama biz gerçekleştirmek zorunda test her aşaması için net ve kesin bir ayar vermek istedim.
Ben de daha sonra bu konuda biraz daha soruşturma işi yapan olacak, ve diğerleri bu baş ağrısı önlemek böylece, ben bu soruya ile gelip herhangi bir bulgu yayınlayacağız.
