1 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • PCI DSS hạn chế việc lưu trữ và hiển thị dữ liệu thẻ, nhưng chỉ với các thông tin được phép như BIN, 4 số cuối và ngày hết hạn, kẻ tấn công vẫn có thể tiếp tục thử thanh toán bổ sung ở các đơn vị chấp nhận thẻ khác
  • Từ một tài khoản bị xâm nhập, kẻ tấn công đã thông qua trang 3D Secure của ngân hàng để biết thẻ còn dùng được hay không, tên ngân hàng, số thẻ đã che một phần và toàn bộ ngày hết hạn, rồi khoảng 6 giờ sau tạo ra các lần thử xác thực ở nhiều đơn vị chấp nhận thẻ
  • Số thẻ thanh toán (PAN) có cấu trúc gồm IIN, mã định danh tài khoản và chữ số kiểm tra Luhn; nếu phản hồi của cổng thanh toán cho biết giá trị nào sai, việc đoán PAN, ngày hết hạn và CVV sẽ trở nên dễ dàng hơn
  • Tốc độ thử nghiệm thực tế là 6 lần mỗi giây, khoảng 2 lần mỗi giây cho mỗi API; IP thay đổi nhờ proxy và số thẻ cũng liên tục khác nhau, khiến phía đơn vị chấp nhận thẻ khó phát hiện brute force
  • Kẻ tấn công đã lợi dụng các đơn vị chấp nhận thẻ thuộc diện miễn 3D Secure để chuyển toàn bộ hạn mức đã hạ xuống vào ví điện tử; tiền được hoàn lại qua chargeback, nhưng cơ chế giới hạn tốc độ CVC2 của ngân hàng chỉ dừng ở mức chặn vài phút

PCI DSS ngăn được gì và còn để sót gì

  • PCI DSS là tiêu chuẩn ngành định nghĩa các biện pháp bảo mật tối thiểu cần có khi xử lý dữ liệu ngân hàng nhạy cảm như thẻ tín dụng, và giới hạn việc lưu trữ cũng như hiển thị để toàn bộ thông tin không bị lộ ngay cả khi tài khoản bị xâm nhập hoặc dữ liệu thẻ rơi vào tay bên thứ ba
  • Theo PCI DSS 4, thông tin có thể hiển thị trên màn hình hoặc biên lai gồm PAN đã che một phần, tên chủ thẻ, mã dịch vụ và ngày hết hạn; PAN có thể hiển thị tới BIN và 4 số cuối
  • Thông tin không được hiển thị gồm toàn bộ dữ liệu track, mã xác minh thẻ và PIN/PIN block
  • Cả website thương mại điện tử lẫn biên lai giấy đều có thể bị ảnh hưởng bởi cùng một vấn đề; thông tin thẻ có thể lộ ra không chỉ qua việc tài khoản bị xâm nhập mà còn từ các biên lai không bị hủy bỏ đúng cách

Diễn biến sự cố

  • Nạn nhân dùng thẻ tín dụng ảo có giới hạn hạn mức, đã bật 3D Secure là hình thức xác thực hai bước, và chỉ lưu thẻ để dùng tại những đơn vị chấp nhận thẻ quen thuộc, có tiếng
  • Sau khi một tài khoản tạo từ lâu bị xâm nhập, tin nhắn SMS về nỗ lực mua hàng trên website có lưu thẻ đã được gửi tới; nạn nhân lập tức đăng nhập, đổi mật khẩu, kiểm tra có mua hàng hay không rồi hạ mạnh hạn mức của thẻ ảo
  • Lý do không vô hiệu hóa hoàn toàn thẻ là vì nạn nhân cho rằng toàn bộ thông tin thẻ chưa bị lộ
  • Khoảng 6 giờ sau lần xâm nhập đầu tiên, có 3–4 lần thử SMS 3D Secure từ nhiều đơn vị chấp nhận thẻ chưa từng dùng; tất cả đều thất bại nhưng sau đó trở thành manh mối quan trọng để hiểu cách thức tấn công
  • Vài phút sau, trong lúc gọi cho ngân hàng để vô hiệu hóa hoàn toàn thẻ, kẻ tấn công đã dùng các đơn vị chấp nhận thẻ khác không có 3D Secure để rút hết hạn mức đã hạ xuống qua nhiều lần thanh toán
  • Số tiền được chuyển vào ví điện tử của một chợ cho phép rút tiền mặt; sau khi yêu cầu chargeback, nạn nhân đã được ngân hàng hoàn tiền

Thông tin mà kẻ tấn công có được

  • Kẻ tấn công thử thanh toán từ tài khoản đã chiếm được, xem trang 3D Secure của ngân hàng rồi hủy đơn hàng và rời đi
  • Trong quá trình đó, chúng biết được rằng thẻ vẫn còn dùng được, tên ngân hàng, số thẻ đã che một phần và toàn bộ ngày hết hạn
  • Thông thường, để hoàn tất thanh toán thẻ bình thường cần có đủ 16 chữ số PAN, ngày hết hạn, mã CVC2 và thông tin như số điện thoại dùng cho 3D Secure
  • Nhưng trong vụ tấn công thực tế, chỉ với một phần thông tin, kẻ tấn công vẫn có thể tiếp tục thử ở các đơn vị chấp nhận thẻ khác

Cấu trúc PAN và khả năng bị đoán

  • Số thẻ thanh toán (PAN) là mã định danh thẻ dùng cho thẻ tín dụng, thẻ ghi nợ, thẻ lưu giá trị và thẻ quà tặng
  • PAN có hệ thống đánh số chung theo ISO/IEC 7812, với cấu trúc nội bộ như sau
    • Issuer Identification Number (IIN) dài 6 hoặc 8 chữ số
    • Mã định danh tài khoản riêng dài tối đa 12 chữ số
    • 1 chữ số kiểm tra được tính bằng thuật toán Luhn
  • Ngân hàng của nạn nhân không cho phép thanh toán chỉ bằng số thẻ mà yêu cầu đồng thời PAN, ngày hết hạn và CVV
  • Một số ngân hàng và cổng thanh toán vẫn có thể xử lý giao dịch chỉ với số thẻ, và đây là điểm mà nạn nhân đặc biệt khó tin

Điều kiện để brute force do phản hồi từ cổng thanh toán tạo ra

  • Ngân hàng của nạn nhân từ chối các thanh toán thiếu hoặc sai giá trị cần thiết, nhưng lại cho biết phần nào sai thông qua mã phản hồi
  • Ví dụ phản hồi như sau
    • “Không phải thẻ tín dụng hợp lệ”
    • “Thẻ đã hết hạn”
    • “Mọi thông tin khác đều đúng nhưng CVV sai”
  • Những phản hồi như vậy có thể được kẻ tấn công dùng để phân biệt giá trị nào trong số thẻ, ngày hết hạn và CVV là đúng hay sai
  • Trong cuộc tấn công thực tế, kẻ tấn công thử ở tốc độ 6 lần mỗi giây, khoảng 2 lần mỗi giây cho mỗi API
  • Tốc độ này rất khó bị phía đơn vị chấp nhận thẻ phát hiện, vì IP nguồn thay đổi nhờ proxy, số thẻ cũng không trùng nhau do đặc tính của brute force, và tần suất yêu cầu rất thấp

Vai trò của các đơn vị chấp nhận thẻ miễn 3D Secure

  • Ngân hàng có danh sách các đơn vị chấp nhận thẻ miễn 3D Secure; những đơn vị này được xem là đối tượng ngân hàng tin cậy nên có thể nhận thanh toán và đăng ký định kỳ mà không cần 3D Secure
  • Các đơn vị này sẽ chịu trách nhiệm nếu xảy ra chargeback
  • Kẻ tấn công đã dùng các đơn vị chấp nhận thẻ không có 3D Secure để chuyển số tiền trong hạn mức thẻ vào ví điện tử

Ứng phó sau đó và những vấn đề còn lại

  • Tiền được hoàn lại nhanh chóng thông qua chargeback
  • Nạn nhân đã báo cho đơn vị chấp nhận thẻ rằng hệ thống đổi thanh toán thẻ thành tiền mặt của họ bị lợi dụng để rút tiền trái phép, nhưng đơn vị này trả lời rằng hãy liên hệ ngân hàng
  • Nạn nhân cũng thông báo cho website thương mại điện tử rằng việc để lộ 10 chữ số số thẻ cùng ngày hết hạn sẽ khiến tấn công trở nên dễ dàng hơn, nhưng website này không công nhận đó là lỗ hổng và trả lời rằng hệ thống được cố ý thiết kế để phù hợp với tiêu chuẩn PCI DSS 3 và 4
  • Những người xây dựng API thanh toán hoặc làm việc trong ngành thanh toán không tỏ ra ngạc nhiên, và một số đơn vị chấp nhận thẻ còn cho biết họ có thể giao dịch ngay cả khi không có ngày hết hạn
  • Sau sự việc, bên từng đổi thanh toán thẻ thành tiền mặt không còn xử lý việc này mà không có 3D Secure nữa
  • Ngân hàng của nạn nhân hiện vẫn áp dụng giới hạn tốc độ khá lỏng cho brute force CVC2; khi chạm ngưỡng, thẻ chỉ bị khóa tạm thời trong vài phút

1 bình luận

 
Ý kiến trên Hacker News
  • Nhìn vào các trường hợp liên quan, có thể tác giả bài gốc đã đang lần theo nguyên nhân sai. Gần đây trên thẻ tín dụng của tôi xuất hiện các khoản thanh toán nhỏ trái phép liên quan đến FB/Meta, trông như ai đó đang thử xem thẻ có bị phát hiện không
    Tôi gọi cho công ty phát hành thẻ để hủy giao dịch và khóa thẻ, rồi nhận thẻ mới với số thẻ, ngày hết hạn và CVV mới, nhưng ngay cả trên chiếc thẻ mới chưa từng dùng đó cũng lại bắt đầu xuất hiện các giao dịch lừa đảo FB/Meta. Nguyên nhân là ví điện tử, và kể cả khi hủy thẻ thì số thẻ cùng các thông tin khác vẫn có thể được chuyển sang qua ví điện tử
    Tôi lại gọi cho công ty phát hành thẻ và yêu cầu hủy tất cả ví điện tử, thì hóa ra có tới 99 cái, và việc này không thể xử lý online mà phải nói chuyện với nhân viên tổng đài. Dù đã được giải thích rằng mọi khoản thanh toán định kỳ sẽ bị đặt lại, tôi vẫn phải yêu cầu hủy cả thẻ lẫn toàn bộ ví điện tử, và còn phải chờ tới 20 phút. Việc “hủy thẻ” có thể không giống như mọi người nghĩ, và vì các khoản thanh toán lặp lại đem lại lợi nhuận rất lớn cho công ty phát hành nên việc hủy có vẻ dẫn tới thất thu đáng kể

    • Tôi không biết có đúng là “ví điện tử” hay không, nhưng khái niệm cập nhật thông tin thẻ sau khi phát hành thẻ mới là có thật và là dịch vụ do công ty phát hành cung cấp
      Blog Stripe: https://stripe.com/resources/more/what-is-a-card-account-upd...
    • Tôi cũng bị Meta/FB tính 200 euro, và vẫn đang chờ thẻ mới
    • Với privacy.com, bạn có thể tự tạo thẻ, và nếu muốn thì dùng mỗi dịch vụ một thẻ riêng
    • Chuyện “không có cách nào hủy toàn bộ ví điện tử online” khác nhau rất nhiều tùy ngân hàng. Ví dụ Bank of America cho phép xem và xóa các thẻ đã thêm vào ví điện tử ngay trên website
    • Trường hợp của tôi thì gần như chắc chắn. Mọi việc xảy ra chỉ trong một ngày, và chiếc thẻ đang dùng là thẻ ảo chỉ được dùng ở một vài trang thương mại điện tử lớn
      Nếu bị lộ ở nơi khác, có lẽ họ đã không cố đăng nhập vào một tài khoản thương mại điện tử không liên quan
  • Bài này bỏ qua phần quan trọng nhất. Thanh toán bù trừ là lúc ngân hàng đồng ý chuyển tiền từ tài khoản của tôi sang bên bán, và việc đó hoàn toàn tách biệt với phê duyệt
    Phê duyệt là các cơ chế như EMV hiện đại, tức xác thực “chip và PIN”, CVV online, cùng nhiều biện pháp để ngân hàng tự bảo vệ mình khỏi gian lận và phụ trợ cho cả bên bán
    Mạng lưới có thể chấp nhận việc Amazon nói rằng “đây là số thẻ, và người này nói họ trả cho chúng tôi 400 đô”. Đó đơn giản là thanh toán bù trừ và nó sẽ lên sao kê. Không có mật mã tinh vi, không có lớp bảo vệ mạnh bằng PIN 4 số, thậm chí không có kiểu xác minh ở mức nhớ họ trước hôn nhân của mẹ, chỉ là “được, tôi tin”. Vì vậy người tiêu dùng sẽ cứ trả nếu không đọc sao kê thẻ tín dụng và khiếu nại các giao dịch lạ
    Mạng lưới hầu như không có động lực quan tâm đến việc người tiêu dùng bị móc túi. Nếu không ai khiếu nại thì mọi bên đều vui, còn nếu có khiếu nại thì chỉ cần thu hồi lại từ bên bán nên cũng không phải vấn đề của họ

    • Câu “nếu khiếu nại thì cứ thu hồi từ bên bán là xong” đúng với thanh toán online không có 3DS, nhưng không đúng với giao dịch trực tiếp hoặc giao dịch online có 3DS. Trong các trường hợp đó thường bên phát hành sẽ chịu trách nhiệm
  • Các đơn vị xử lý thanh toán không cho phép liệt kê thẻ hay thử thẻ bằng cách brute force toàn bộ số thẻ, và mạng lưới thẻ cũng áp dụng hình phạt nặng với các bên bán và đơn vị xử lý không chặn việc này

    1. https://stripe.com/newsroom/news/card-testing-surge
    2. https://stripe.com/blog/the-ml-flywheel-how-we-continually-i...
    3. https://docs.stripe.com/disputes/monitoring-programs#enumera...
    • Nếu dùng nhiều API xác minh thẻ khác nhau thì tần suất thử sẽ rất thấp. Nếu là các số PAN khác nhau, IP nguồn khác nhau, tôi không rõ phải liên hệ chúng với nhau bằng cách nào
      Còn brute force CVC2 trên một PAN duy nhất là câu chuyện khác
    • Mới khoảng 6 năm trước thôi, Stripe vẫn không hề che số thẻ trong log API
  • Đây là bằng chứng cho thấy hạ tầng chống gian lận thực sự đã bảo vệ bạn. Ngân hàng gánh tổn thất do gian lận và cũng hoàn tiền lại
    Rốt cuộc hệ thống ngân hàng có quan tâm đến tổn thất do gian lận, và cũng rất giỏi phát hiện gian lận. Hệ thống thanh toán bằng thẻ quá lớn nên cực kỳ khó thay đổi, vì thế nếu không có bằng chứng mạnh rằng một thay đổi cụ thể thực sự làm giảm tỷ lệ gian lận thì ngân hàng sẽ chọn không thay đổi

    • Tiếc là trong khá nhiều trường hợp, người gánh tổn thất do gian lận không phải ngân hàng mà là bên bán, nên phát sinh vấn đề chủ thể-người đại diện
      Ngân hàng phát hành kiếm phí thanh toán bù trừ trên mọi giao dịch, nên nếu không phải chịu trách nhiệm gian lận thì động cơ mặc định là phê duyệt càng nhiều càng tốt rồi xử lý sau bằng chargeback. Tuy nhiên 3DS làm thay đổi tính toán này khá nhiều, và giao dịch trực tiếp cũng thường là trách nhiệm của ngân hàng phát hành
    • Không phải ngân hàng thực sự gánh lỗ, mà là họ đã cộng thêm biên lợi nhuận đủ để hấp thụ chi phí gian lận vào mọi dịch vụ
      Cuối cùng thì mọi người tiêu dùng cùng gánh toàn bộ chi phí gian lận. Chỉ là nó không hiện thành một dòng riêng trên hóa đơn; chúng ta đang trả thêm một chút trong mọi món hàng mình mua
    • Bạn chỉ được bảo vệ khi nhận ra giao dịch gian lận
    • Tôi từng thấy ngân hàng bỏ cuộc khi gặp đối thủ chargeback có động lực rất mạnh
      Khi tôi gặp chuyện liên quan đến thẻ tín dụng bị đánh cắp trên eBay, ban đầu mọi thứ diễn ra khá tốt, nhưng sau khi eBay gửi cả chồng giấy tờ cho ngân hàng thì chargeback bị lật ngược, và không lâu sau tài khoản ngân hàng của tôi cũng bị đóng
      Không phải cứ được hoàn tiền qua chargeback là xong. Ban đầu có vẻ chỉ là xử lý tạm trong lúc cho bên kia thời gian phản hồi, rồi eBay dùng giấy tờ dìm tôi xuống và phải mất khoảng 30 ngày để chargeback bị đảo lại lần nữa. Cách họ giải thích thuyết phục đến mức ngân hàng của tôi còn xem tôi như kẻ gian lận
      Tôi cũng không chắc chuyện ngân hàng gánh tổn thất gian lận có đúng 100% không. Lý do bên bị chargeback lại đi tranh chấp là vì rốt cuộc hoặc bên bị chargeback, hoặc bên khởi tạo chargeback, sẽ phải gánh lỗ. Nếu cấu trúc là ngân hàng ăn khoản lỗ đó thì eBay đâu cần thuê nhân sự chuyên trách để điều tra và phản hồi chargeback của tôi
  • Sẽ hữu ích hơn rất nhiều nếu 3D Secure là bắt buộc ở khắp nơi, nhưng theo tôi hiểu thì ở Mỹ gần như không dùng. Vì thị trường Mỹ quá lớn nên các đơn vị phát hành thẻ buộc phải chấp nhận các yêu cầu không có 3D Secure, nếu không khách hàng sẽ không dùng được thẻ ở quá nhiều nơi
    Thành ra một biện pháp chống gian lận rất mạnh lại bị hạn chế nặng nề, điều này khá khó chịu nếu nhìn từ phần còn lại của thế giới
    Tôi không hiểu tại sao người tiêu dùng Mỹ lại dường như thích bị gian lận hơn là chịu một chút bất tiện. Ngay cả khi không phải nạn nhân trực tiếp, ai cũng vẫn trả tiền vì bên bán cộng chi phí gian lận và bảo hiểm vào giá sản phẩm

    • Thông thường người ta đánh giá theo kiểu nếu mức giảm chuyển đổi do một biện pháp bảo mật nào đó gây ra lớn hơn tỷ lệ gian lận trung bình thì không có lý do tài chính để triển khai
      Tuy vậy nếu nhìn toàn ngành thì đây là một vấn đề điều phối điển hình. Tỷ lệ chuyển đổi giảm là vì vẫn còn lựa chọn dễ hơn; nếu mọi bên bán và ngân hàng cùng lúc bắt buộc 3DS thì sẽ không còn lựa chọn thuận tiện hơn để chuyển sang. Dù thích hay không, người dùng sẽ quen với cách mới an toàn hơn và tỷ lệ chuyển đổi lại tăng lên
      Việc EU bắt buộc 3DS cho nhiều khoản thanh toán là theo hướng này, dù ở đó cơ quan quản lý cũng thừa nhận áp dụng 100% sẽ phản tác dụng, nên có một điểm cân bằng ở đâu đó ở giữa
      Một ví dụ khác theo cùng nguyên lý là thẻ tín dụng Mỹ không có PIN. Nếu một ngân hàng đơn lẻ đưa PIN vào thì khách hàng sẽ chuyển sang dùng thẻ của đối thủ không có PIN và mức sử dụng sẽ giảm mạnh. Ở các thị trường khác, nhờ can thiệp của cơ quan quản lý hoặc ưu đãi từ mạng lưới thẻ, mọi thẻ đều có PIN và người dân đơn giản là đã quen với điều đó
    • Luật ở Mỹ khác và thân thiện với người tiêu dùng hơn, nên hành vi người tiêu dùng cũng khác
      Thời kỳ đầu của thẻ tín dụng, tức khi nó bắt đầu ở Mỹ, Quốc hội đã thông qua Fair Credit Billing Act năm 1974, giới hạn trách nhiệm của người tiêu dùng ở mức 50 đô nếu báo mất thẻ trong vòng 60 ngày sau khi kỳ sao kê chứa giao dịch gian lận kết thúc. Khi đó thanh toán được xử lý hoàn toàn offline trên giấy bằng những chiếc máy in hóa đơn thẻ phát ra tiếng “kachunk”
      Luật này không thay đổi, và trên thực tế đa số ngân hàng còn miễn luôn cả 50 đô, không quy trách nhiệm gì cho chủ thẻ trong các trường hợp được báo cáo. Với ngân hàng thì chẳng đáng để làm khách hàng khó chịu chỉ vì 50 đô
      Nhờ Internet, thẻ bỗng nhiên dễ bị đánh cắp và lạm dụng hơn rất nhiều, nhưng các ngân hàng vẫn phải gánh toàn bộ thiệt hại được báo trong vòng 60 ngày sau khi kỳ sao kê kết thúc. Vì vậy các ngân hàng Mỹ đầu tư cực lớn vào giám sát thời gian thực giao dịch thẻ tín dụng, và do cuối cùng chính họ chịu trách nhiệm nên họ giám sát rất nghiêm túc. Ngược lại, người tiêu dùng bận tâm ít hơn. Từ góc nhìn người tiêu dùng, lý do thẻ ở Mỹ trông lỏng lẻo hơn nhiều so với thẻ châu Âu là vì khác với châu Âu, người tiêu dùng được miễn trách nhiệm nên ngân hàng đã đầu tư vào tầng phía sau nhiều hơn hẳn
      Riêng EU thì có quy định trần phí thanh toán bù trừ mà công ty thẻ có thể thu, còn Mỹ thì không giới hạn. Kết quả là chủ thẻ ở Mỹ có thể nhận được phần thưởng dùng thẻ khá lớn, đặc biệt rõ ở nhóm 10% giàu nhất, điều gần như không thể có với thẻ phát hành ở EU nơi phí thanh toán bù trừ bị khống chế
      Hiện đang có một vụ kiện lớn nhằm cho phép bên bán chỉ chấp nhận các thẻ phí thấp. Hợp đồng tiêu chuẩn của VISA/MC/AMEX yêu cầu đối xử như nhau với mọi thẻ, và điều này tạo động lực cho công ty thẻ đẩy người dùng sang các thẻ có phí thanh toán bù trừ cao hơn. Còn phải chờ kết quả vụ kiện đó, nhưng cho đến lúc ấy người tiêu dùng chi tiêu lớn ở Mỹ vẫn có thể nhận phần thưởng thẻ cao hơn nhiều, và điều này cũng thúc đẩy việc dùng thẻ và giảm ma sát so với thẻ kiểu EU
    • Bạn nghĩ rằng chúng tôi đang yêu cầu một phương thức thanh toán kém an toàn hơn sao?
      Không phải chúng tôi thích bị gian lận, mà đây là vấn đề thương lượng giữa bên phát hành thẻ và bên bán
    • Nhân tiện, nếu bạn ở Mỹ và muốn thì HSBC USA Mastercard có dùng 3D Secure
    • Không rõ 3D Secure có thể ngăn được bao nhiêu tổn thất do gian lận, cỡ 0,1% chăng?
  • Trước đây công ty tôi từng tuyển một người, rồi người đó bắt đầu khoe rằng mình tìm ra cách nạp giá trị lưu trữ vào gift card. Về sau mới biết anh ta đang bị FBI điều tra
    Lại còn là nhà thầu chính phủ nữa, và cuối cùng nhân viên an ninh to nhất mà tôi từng thấy đã tới đưa anh ta đi

    • “Nạp giá trị lưu trữ vào gift card” nghĩa là gì vậy?
  • Thẻ tín dụng ảo đã có từ lâu rồi. Tôi nhớ hơn 15 năm trước Bank of America hay Citi đã cung cấp, có thể là ứng dụng Java hoặc file thực thi riêng. Tôi ngạc nhiên vì sao nó không phổ biến hơn
    Robinhood triển khai cái này cực tốt. Đây là hệ thống thẻ tín dụng ảo tốt nhất tôi từng dùng và rất mượt. Bạn có thể cho phép thẻ dùng một lần, trong 24 giờ, hoặc vô thời hạn cho đến khi hủy, và UI/UX rất tuyệt

    • Nó không phổ biến vì gánh chi phí gian lận dễ hơn là duy trì hệ thống đó. Đơn giản là một tính năng có lợi cho người tiêu dùng nên nó không bén rễ được
    • MBNA từng có ứng dụng thẻ ảo dựa trên Flash vào đầu những năm 2000, trước khi bị Chase mua lại, và tôi dùng rất hiệu quả
      Tôi không hiểu vì sao trong thời đại mọi thứ đều là thuê bao như bây giờ mà tính năng này vẫn không phổ biến. Khả năng đặt ngày hết hạn và hạn mức chi tiêu để khỏi phải thương lượng bẩn thỉu khi hủy thuê bao là cực kỳ hay
  • Gần đây tôi nhận được tin nhắn từ ngân hàng nói rằng có một giao dịch đáng ngờ ở nước ngoài bằng thẻ của vợ tôi, nhưng số tiền theo đúng nghĩa đen là 0 đô, và xảy ra vào lúc cô ấy không hề dùng điện thoại hay máy tính
    Ban đầu tôi nghĩ chính tin nhắn đó là lừa đảo, nhưng khi kiểm tra online thì thấy định dạng tin nhắn khớp, và trang web ngân hàng cũng đảm bảo rằng quy trình phản hồi không yêu cầu bất kỳ thông tin nào nên tôi xác nhận là mình không thực hiện giao dịch đó
    Ngân hàng lập tức hủy thẻ và gửi thẻ mới
    Lúc đầu tôi tưởng hệ thống an ninh của ngân hàng phản ứng thái quá, nhưng thực ra có vẻ ai đó đang làm đúng kiểu được mô tả trong bài này, và ngân hàng đã phát hiện sớm hơn

  • Nên có riêng một thẻ cho thanh toán online và chỉ nạp vào đó đúng số tiền cần dùng
    Tôi biết đó là suy nghĩ ngây thơ
    Quay lại bài viết, điểm yếu là mật khẩu, và nó dẫn sang các bên bán khác không dùng 3D Secure
    Đọc bài thì có vẻ kẻ tấn công có hẳn một hệ thống tự động hoàn chỉnh, nên các bên bán lớn cần xử lý các nỗ lực đăng nhập tự động vào nhiều tài khoản khác nhau từ cùng một địa chỉ IP. Ngay cả khi nhìn log Wordfence của chúng tôi thì vòng quay IP cũng không nhanh đến thế, nên có vẻ chặn IP vĩnh viễn vẫn đối phó được phần nào

    • Nếu trong trạng thái hiện tại bên bán không phải chịu trách nhiệm cho gian lận phát sinh thì tại sao họ phải làm vậy?
    • Thành thật mà nói, tôi thường không quan tâm lắm đến gian lận thẻ tín dụng vì ngân hàng sẽ hoàn lại tiền. Tôi chỉ kiểm tra xem sao kê có gì lạ không thôi
    • Mercury giờ đã cung cấp tài khoản ngân hàng cá nhân. Bạn có thể tạo thẻ ghi nợ ảo như ở các dịch vụ cho doanh nghiệp kiểu Brex/Mercury/Ramp
    • Tôi đồng ý về chuyện dùng thẻ riêng. Tôi cũng dùng thẻ riêng, và nhờ vậy số tiền không quá lớn nên cũng đỡ
      Tôi không nghĩ việc lộ mật khẩu lại nên dẫn đến lộ toàn bộ dữ liệu thẻ tín dụng. Cùng loại dữ liệu đó còn được in trên hóa đơn giấy ngoài cửa hàng, có khi 4 chữ số, có khi 10 chữ số. Ngay cả hóa đơn giấy bị bỏ lại trong cửa hàng cũng vẫn có thể đủ để brute force
    • Không liên quan trực tiếp, nhưng thẻ ảo Capital One Eno rất hợp cho mục đích này
  • Bổ sung thêm, bên bán không thể chọn mức độ bảo mật mà họ muốn từ đơn vị xử lý thẻ tín dụng. Ví dụ trên authorize.net, họ vẫn có thể nhận thanh toán ngay cả khi địa chỉ không khớp
    Câu hỏi thực sự là tiền đã bị rút ra bằng cách nào. Có phải họ dùng để mua gift card ở một bên bán bảo mật lỏng lẻo không?
    Đoán ra số là một chuyện, còn đưa tiền ra khỏi hệ thống lại là chuyện hoàn toàn khác

    • Câu “bên bán không thể chọn mức độ bảo mật họ muốn ở đơn vị xử lý thanh toán” còn tùy đơn vị xử lý. Nhiều bên cho phép bên bán cấu hình quy tắc phê duyệt ở mức khá sâu
      Thị trường đơn vị xử lý có phần hơi phân cực. Một phía tập trung vào sự đơn giản và giảm gánh nặng cho khách hàng, phía kia thì phơi toàn bộ độ phức tạp ra và trao quyền kiểm soát chi tiết. Nhóm đầu sẽ không cho bạn chỉ định yêu cầu bảo mật, nhóm sau thì đưa ra hàng trăm tùy chọn. Tất nhiên cũng có những đơn vị xử lý nằm ở khoảng giữa, và hai trục này thường nhắm đến các nhóm khách hàng khác nhau