2008-09-19 32 views
17

Chúng tôi có một hệ thống mà chúng tôi muốn ngăn chặn cùng một số thẻ tín dụng được đăng ký cho hai tài khoản khác nhau. Vì chúng tôi không lưu trữ số thẻ tín dụng nội bộ - chỉ bốn chữ số cuối cùng và ngày hết hạn - chúng tôi không thể chỉ đơn giản so sánh số thẻ tín dụng và ngày hết hạn. Ý tưởng hiện tại của chúng tôi là lưu trữ hàm băm (SHA-1) trong hệ thống thông tin thẻ tín dụng của chúng tôi khi thẻ được đăng ký và so sánh các thẻ băm để xác định xem thẻ đã được sử dụng trước đó hay chưa.Cách tốt nhất để tránh sử dụng thẻ tín dụng trùng lặp

Thông thường, một muối được sử dụng để tránh các cuộc tấn công từ điển. Tôi cho rằng chúng ta dễ bị tổn thương trong trường hợp này, vì vậy có lẽ chúng ta nên lưu trữ một muối cùng với hàm băm.

Các bạn có thấy bất kỳ sai sót nào trong phương pháp này không? Đây có phải là cách tiêu chuẩn để giải quyết vấn đề này không?

Trả lời

0

Có, việc so sánh băm sẽ hoạt động tốt trong trường hợp này.

0

Hàm băm muối sẽ hoạt động tốt. Có một hệ thống muối cho mỗi người dùng nên có nhiều bảo mật.

+0

Tôi đồng ý. Hãy ghi nhớ rằng điều này làm cho việc đăng ký một thẻ tín dụng một hoạt động O (n) trong đó n là số thẻ hiện có đã đăng ký. Cộng với băm là một hoạt động khá tốn kém. – Johan

1

So sánh băm là một giải pháp tốt. Hãy chắc chắn rằng bạn không chỉ muối tất cả các số thẻ tín dụng với cùng một muối liên tục, mặc dù. Sử dụng một loại muối khác (như ngày hết hạn) trên mỗi thẻ. Điều này sẽ làm cho bạn khá không thấm vào các cuộc tấn công từ điển.

Từ this Coding Horror article:

Thêm một chặng đường dài, muối ngẫu nhiên duy nhất cho mỗi mật khẩu bạn lưu trữ. Điểm của một muối (hoặc nonce, nếu bạn thích) là để làm cho mỗi mật khẩu duy nhất và đủ lâu để tấn công brute force là một sự lãng phí thời gian. Vì vậy, mật khẩu của người dùng, thay vì được lưu trữ dưới dạng băm của "myspace1", sẽ được lưu trữ dưới dạng băm của 128 ký tự của chuỗi unicode ngẫu nhiên + "myspace1". Bây giờ bạn hoàn toàn miễn dịch với tấn công bảng cầu vồng.

+0

Có, nhưng nếu bạn sử dụng một loại muối ngẫu nhiên khác nhau cho mỗi băm, bạn cần phải thử mọi muối trên giá trị mới mà bạn muốn so sánh. Sử dụng ngày hết hạn chuỗi ngẫu nhiên nhưng không đổi dài. –

+0

Nếu bạn đang sử dụng ngày hết hạn trong muối, thì nó tồn tại như thế nào? – ine

+0

Trừ khi họ đang sử dụng một từ điển bao gồm ngày hết hạn như muối. –

1

Một ý tưởng hay.

Lưu trữ chỉ băm là một ý tưởng hay, nó đã phục vụ trong thế giới mật khẩu trong nhiều thập kỷ.

Thêm muối có vẻ như như ý tưởng hợp lý và thực sự tạo ra một cuộc tấn công bạo lực mạnh mẽ hơn cho kẻ tấn công. Nhưng muối đó sẽ tốn nhiều công sức cho bạn khi bạn thực sự kiểm tra để đảm bảo rằng CC mới là duy nhất: Bạn sẽ phải SHA-1 số CC mới N lần, trong đó N là số lượng muối bạn có đã được sử dụng cho tất cả các CC bạn đang so sánh nó với. Nếu thực sự bạn chọn muối ngẫu nhiên tốt, bạn sẽ phải thực hiện băm cho mỗi thẻ khác trong hệ thống của bạn. Vì vậy, bây giờ nó là bạn làm các lực lượng vũ phu. Vì vậy, tôi sẽ nói đây không phải là một giải pháp có thể mở rộng. Bạn thấy đấy, trong thế giới mật khẩu, một muối không có thêm chi phí bởi vì chúng tôi chỉ muốn biết liệu văn bản rõ ràng + băm muối vào những gì chúng tôi đã lưu trữ cho người dùng cụ thể này hay chưa. Yêu cầu của bạn thực sự là khá khác nhau.

Bạn sẽ phải cân nhắc thương mại. Thêm muối không làm cho cơ sở dữ liệu của bạn an toàn nếu nó bị đánh cắp, nó chỉ làm cho việc giải mã trở nên khó khăn hơn. Bao nhiêu khó khăn hơn? Nếu nó thay đổi cuộc tấn công từ yêu cầu 30 giây để yêu cầu một ngày bạn đã đạt được không có gì - nó vẫn sẽ được giải mã. Nếu nó thay đổi nó từ một ngày đến 30 năm bạn đã đạt được đôi khi đáng xem xét.

+0

Ah - và nếu SHA-1 đắt đến mức thêm vào muối đó thì thực tế sẽ tốn kém trong năm hacker thì nó cũng sẽ đắt đến nỗi bạn có thể sẽ phải chịu thêm số lượng 10,000. Nhưng bạn luôn có thể kiểm tra nó so với kích thước cơ sở khách hàng dự kiến ​​của bạn và xem nó có đau không. – Jeff

+2

-1 Tôi xin lỗi, nhưng tôi thực sự không đồng ý với câu trả lời này: bạn không thể xử lý số thẻ tín dụng như mật khẩu vì mọi người có thể chọn mật khẩu phức tạp nếu cần (dài, với chữ cái, chữ số và ký tự đặc biệt), trong khi số thẻ tín dụng chỉ khoảng 16 chữ số, và một nửa trong số chúng có thể được đoán dễ dàng (7 đầu là tiêu chuẩn công nghiệp (xem câu trả lời của Nick Johnson) và 4 số cuối được lưu trữ trong cơ sở dữ liệu, theo câu hỏi (và đây là thực tế phổ biến). Thay vào đó, hãy làm theo câu trả lời của Wedge, hoặc của tôi – MiniQuark

+1

-1 MiniQuark là đúng. Đề án này là kém hơn so với các đề xuất khác được thực hiện ở đây. ở đây – Accipitridae

0

SHA1 là broken.Tất nhiên, không có nhiều thông tin về sự thay thế tốt. SHA2?

+1

Cả hai SHA1 và MD5 chỉ bị phá vỡ trong đó có thể tạo ra hai chuỗi với cùng một băm.Không bị hỏng khi nói đến tính toán preimages cho một băm, hoặc khi nói đến việc tạo ra một chuỗi với cùng một băm như một chuỗi đã biết. –

0

Nếu bạn kết hợp 4 số cuối của số thẻ với tên của chủ thẻ (hoặc chỉ họ) và ngày hết hạn, bạn sẽ có đủ thông tin để làm cho bản ghi duy nhất. Hashing là tốt đẹp cho an ninh, nhưng bạn sẽ không cần phải lưu trữ/thu hồi muối để nhân rộng các hash cho một kiểm tra trùng lặp?

+0

có bạn sẽ - điểm là các cuộc tấn công dựa trên bảng mất nhiều thời gian để tạo ra. Nếu bạn có một muối khác nhau cho mỗi số thẻ, việc xây dựng bảng sẽ chỉ nhận được bạn, nhiều nhất là 1 thẻ. Chi phí không đáng giá. –

+0

Tôi đã ủng hộ chống lại băm muối - Tôi nghĩ rằng nó quá mức cần thiết khi mục đích của OP là đơn giản ngăn chặn nhiều phiên bản dữ liệu mà bản thân họ không đủ độc đáo để chống lại. –

0

Tôi nghĩ rằng một giải pháp tốt như được gợi ý ở trên, sẽ là lưu trữ giá trị băm của Số thẻ nói, Ngày hết hạn và tên. Bằng cách đó bạn vẫn có thể so sánh nhanh chóng ...

2

@Cory R. King

SHA 1 không bị hỏng, mỗi lần. Điều mà bài báo cho thấy là có thể tạo ra 2 chuỗi có giá trị băm giống nhau trong thời gian ngắn hơn. Bạn vẫn không thể tạo một chuỗi tương đương với hàm băm SPECIFIC trong một khoảng thời gian hợp lý. Có một sự khác biệt lớn giữa hai người.

0

Sha1 bị hỏng không phải là vấn đề ở đây. Tất cả các phương tiện bị hỏng là có thể tính toán va chạm (2 tập dữ liệu có cùng sha1) dễ dàng hơn bạn mong đợi. Điều này có thể là một vấn đề khi chấp nhận các tệp tùy ý dựa trên sha1 của chúng nhưng nó không có sự liên quan cho một ứng dụng băm bên trong.

3

PCI DSS tuyên bố rằng bạn có thể lưu trữ PAN (số thẻ tín dụng) bằng cách sử dụng băm một chiều mạnh mẽ. Họ thậm chí không yêu cầu nó được muối. Điều đó nói rằng bạn nên muối nó với một giá trị duy nhất cho mỗi thẻ. Ngày hết hạn là một khởi đầu tốt nhưng có lẽ hơi quá ngắn. Bạn có thể thêm vào các thông tin khác từ thẻ, chẳng hạn như nhà phát hành. Bạn không nên sử dụng số CVV/bảo mật vì bạn không được phép lưu trữ nó. Nếu bạn sử dụng ngày hết hạn thì khi chủ thẻ được cấp một thẻ mới có cùng số tiền, thẻ sẽ được tính là một thẻ khác. Điều này có thể là một điều tốt hay xấu tùy thuộc vào yêu cầu của bạn.

Cách tiếp cận để làm cho dữ liệu của bạn an toàn hơn là làm cho mỗi hoạt động tính toán tốn kém. Ví dụ nếu bạn md5 hai lần nó sẽ mất một kẻ tấn công còn để crack các mã.

Nó khá tầm thường để tạo số thẻ tín dụng hợp lệ và cố gắng tính phí cho mỗi ngày hết hạn có thể. Tuy nhiên, nó là tốn kém tính toán. Nếu bạn làm cho nó tốn kém hơn để crack băm của bạn thì nó sẽ không có giá trị cho bất cứ ai bận tâm; ngay cả khi họ có muối, băm và phương pháp bạn đã sử dụng.

10

Mọi người đang suy nghĩ về thiết kế của điều này, tôi nghĩ vậy. Sử dụng hàm băm có độ mặn cao, an toàn (ví dụ: "tính toán đắt tiền") như sha-256, với một muối duy nhất cho mỗi bản ghi.

Trước tiên, bạn nên thực hiện kiểm tra độ chính xác cao, chi phí thấp, sau đó thực hiện kiểm tra dứt khoát chi phí cao nếu lần kiểm tra đó được thực hiện.

Bước 1:

Look cho trận đấu với 4 chữ số cuối cùng (và ngày có thể cũng là điểm kinh nghiệm, mặc dù có một số tinh tế đó mà có thể cần phải giải quyết.).

Bước 2:

Nếu kiểm tra đơn giản chạm, sử dụng muối, nhận giá trị băm, thực hiện kiểm tra chuyên sâu.

4 chữ số cuối của cC# là số duy nhất (một phần vì nó bao gồm cả số kiểm tra LUHN) nên phần trăm kiểm tra sâu bạn sẽ thực hiện sẽ không phù hợp (tỷ lệ dương giả) sẽ rất, rất thấp (một phần nhỏ của một phần trăm), giúp bạn tiết kiệm rất nhiều chi phí liên quan đến thiết kế ngây thơ "làm kiểm tra băm mỗi lần".

+0

Điều đó nghe có vẻ giống như một ý tưởng hay, để kiểm tra 4 chữ số cuối cùng trước khi so sánh băm. Cảm ơn! –

+2

Lưu trữ 4 chữ số cuối cùng sẽ đơn giản hóa thêm một cuộc tấn công bạo lực nữa. –

+0

@Arachnid Đáng buồn thay, lưu trữ 4 chữ số cuối cùng là thông lệ phổ biến cho người bán. Tuy nhiên, bạn chỉ có thể so sánh với ngày hết hạn là thử nghiệm đầu tiên nếu bạn hoàn toàn không muốn giữ 4 chữ số cuối cùng. – Wedge

17

Hãy làm một phép tính nhỏ: Số thẻ tín dụng dài 16 chữ số. Bảy chữ số đầu tiên là số 'ngành công nghiệp lớn' và số tổ chức phát hành, và chữ số cuối cùng là tổng kiểm tra luhn. Điều đó để lại 8 chữ số 'miễn phí', cho tổng số 100.000.000 số tài khoản, nhân với số lượng số nhà phát hành tiềm năng (không có khả năng là rất cao). Có những triển khai có thể làm hàng triệu băm mỗi giây trên phần cứng hàng ngày, vì vậy không có vấn đề gì bạn làm muối, đây sẽ không phải là một vấn đề lớn đối với sức mạnh vũ phu.

Bằng sự trùng hợp tuyệt đối, khi tìm kiếm một cái gì đó cho các tiêu chuẩn thuật toán băm, tôi thấy this article about storing credit card hashes, mà nói:

Lưu trữ thẻ tín dụng sử dụng một đường chuyền đơn đơn giản của một thuật toán băm, ngay cả khi ướp muối, là fool- khỏe mạnh. Nó chỉ là quá dễ dàng để bạo lực các số thẻ tín dụng nếu băm bị tổn hại.

...

Khi băm số thẻ tín dụng, băm phải được thiết kế cẩn thận để bảo vệ chống lại brute buộc bằng cách sử dụng có sẵn chức năng mạnh mật mã băm, giá trị muối lớn, và nhiều lần lặp lại.

Bài viết đầy đủ cũng đáng đọc kỹ. Thật không may, upshot dường như là bất kỳ trường hợp nào làm cho nó 'an toàn' để lưu trữ số thẻ tín dụng băm cũng sẽ làm cho nó cực kỳ tốn kém để tìm kiếm các bản sao.

5

Đỗ không cửa hàng đơn giản SHA-1 của số thẻ tín dụng, nó sẽ là cách để dễ dàng để crack (đặc biệt là kể từ khi 4 chữ số cuối cùng được biết). Chúng tôi đã có cùng một vấn đề trong công ty của tôi: đây là cách chúng tôi giải quyết nó.

giải pháp đầu tiên

  1. Đối với mỗi thẻ tín dụng, chúng tôi lưu trữ 4 chữ số cuối cùng, ngày hết hạn, một muối ngẫu nhiên dài (dài 50 byte), và băm ướp muối của số CC. Chúng tôi sử dụng thuật toán bcrypt băm vì nó rất an toàn và có thể được điều chỉnh để có mức độ chuyên sâu CPU như bạn mong muốn. Chúng tôi đã điều chỉnh nó là rất tốn kém (khoảng 1 giây mỗi băm trên máy chủ của chúng tôi!). Nhưng tôi đoán bạn có thể sử dụng SHA-256 thay vào đó và lặp lại nhiều lần nếu cần.
  2. Khi nhập số CC mới, chúng tôi bắt đầu bằng cách tìm tất cả các số CC hiện có kết thúc bằng 4 chữ số và có cùng ngày hết hạn. Sau đó, đối với mỗi CC phù hợp, chúng tôi kiểm tra xem mã băm được lưu trữ của nó có khớp với hàm băm muối được tính từ muối của nó và số CC mới không. Nói cách khác, chúng tôi kiểm tra xem có hay không hash(stored_CC1_salt+CC2)==stored_CC1_hash.

Vì chúng tôi có khoảng 100k thẻ tín dụng trong cơ sở dữ liệu của mình, chúng tôi cần tính khoảng 10 băm, vì vậy chúng tôi nhận được kết quả sau khoảng 10 giây. Trong trường hợp của chúng tôi, điều này là tốt, nhưng bạn có thể muốn điều chỉnh bcrypt xuống một chút. Thật không may, nếu bạn làm thế, giải pháp này sẽ kém an toàn hơn. Mặt khác, nếu bạn điều chỉnh bcrypt để có nhiều CPU hơn, nó sẽ mất nhiều thời gian hơn để phù hợp với số CC.

Mặc dù tôi tin rằng giải pháp này là cách tốt hơn chỉ đơn giản là lưu trữ một băm chưa được định trước của số CC, nó sẽ không ngăn chặn một tên cướp biển rất có động cơ (người quản lý để có được một bản sao của cơ sở dữ liệu) thẻ trong thời gian trung bình từ 2 đến 5 năm. Vì vậy, nếu bạn có 100k thẻ tín dụng trong cơ sở dữ liệu của mình và nếu tên cướp biển có số của CPU thì anh ấy có thể khôi phục một số thẻ tín dụng mỗi ngày!

Điều này dẫn tôi đến sự tin tưởng rằng bạn không nên tự tính giá trị băm: bạn phải ủy quyền cho người khác. Đây là giải pháp thứ hai (chúng tôi đang trong quá trình chuyển sang giải pháp thứ hai này).

giải pháp thứ hai

Đơn giản chỉ cần có cung cấp dịch vụ thanh toán của bạn tạo ra một bí danh cho thẻ tín dụng của bạn.

  1. cho mỗi thẻ tín dụng, bạn chỉ cần lưu trữ bất cứ điều gì bạn muốn lưu trữ (ví dụ 4 chữ số cuối & ngày hết hạn) cộng một số thẻ tín dụng bí danh.
  2. khi nhập số thẻ tín dụng mới, bạn liên hệ với nhà cung cấp thanh toán và cung cấp số CC (hoặc chuyển hướng khách hàng đến nhà cung cấp thanh toán và nhập số CC trực tiếp trên trang web của nhà cung cấp thanh toán). Đổi lại, bạn nhận được bí danh thẻ tín dụng! Đó là nó. Tất nhiên bạn nên đảm bảo rằng nhà cung cấp thanh toán của bạn cung cấp tùy chọn này và bí danh được tạo thực sự an toàn (ví dụ: đảm bảo họ không chỉ tính toán SHA-1 trên số thẻ tín dụng!). Bây giờ cướp biển phải phá vỡ hệ thống của bạn cộng hệ thống của nhà cung cấp thanh toán của bạn nếu anh ta muốn khôi phục số thẻ tín dụng.

Thật đơn giản, nhanh, an toàn (ít nhất, nếu nhà cung cấp thanh toán của bạn). Vấn đề duy nhất tôi thấy là nó liên kết bạn với nhà cung cấp thanh toán của bạn.

Hy vọng điều này sẽ hữu ích.

2

Tôi tin rằng tôi đã tìm được cách thức chống lừa đảo để giải quyết vấn đề này. Ai đó hãy sửa tôi nếu có một lỗi trong giải pháp của tôi.

  1. Tạo máy chủ bảo mật trên EC2, Heroku, v.v. Máy chủ này sẽ phục vụ MỘT mục đích và CHỈ một mục đích: băm thẻ tín dụng của bạn.
  2. Cài đặt máy chủ web bảo mật (Node.js, Rails, vv) trên máy chủ đó và thiết lập cuộc gọi REST API.
  3. Trên máy chủ đó, sử dụng một muối duy nhất (1000 ký tự) và SHA512 nó 1000 lần.

Bằng cách đó, ngay cả khi tin tặc nhận được băm của bạn, họ sẽ cần phải đột nhập vào máy chủ của bạn để tìm công thức của bạn.

0

Nếu bạn đang sử dụng một bộ xử lý thanh toán như Stripe/Braintree, hãy để họ thực hiện việc "nâng hạng nặng".

Cả hai dấu vân tay phục vụ thẻ mà bạn thể yên tâm lưu trữ trong db của bạn và so sánh sau đó để xem nếu thẻ này đã tồn tại:

  • sọc trả fingerprint chuỗi - xem doc
  • Braintree trả unique_number_identifier string - xem doc
Các vấn đề liên quan