2010-03-23 39 views
5

Kịch bản là tôi muốn mã hóa số tài chính trong một cột có kiểu dữ liệu int trong bảng máy chủ sql. Đây là một ứng dụng lớn nên rất khó thay đổi kiểu dữ liệu cột bảng từ int sang bất kỳ kiểu dữ liệu nào khác.Có phương pháp mã hóa cho một cột có kiểu dữ liệu int không?

Tôi đang sử dụng máy chủ sql 2005 và asp.net C#.

Có phương pháp mã hóa hai chiều cho một cột có loại dữ liệu int không?

Tôi có thể sử dụng chức năng do người dùng xác định trong máy chủ sql 2005 hoặc phương pháp C# không?

+0

Bạn muốn đạt được mục tiêu chính xác nào ở đây? Có vẻ như không hợp lý và tôi không thực sự biết cách trả lời nhiều hơn "không" hoặc "có" ở đây. – TomTom

+0

Tôi quan tâm đến bạn vì bạn có thể có một số lỗi thiết kế bảo mật nghiêm trọng trong ứng dụng. Có lẽ nếu bạn cung cấp bối cảnh là tại sao bạn muốn thực hiện bảo mật theo cách này, chúng tôi có thể cung cấp giải pháp cho vấn đề nguyên nhân gốc. –

+0

@ John Sansom: Kịch bản rất đơn giản. Chúng tôi muốn dữ liệu tài chính của mình được mã hóa trong cơ sở dữ liệu vì lý do bảo mật. – Mike108

Trả lời

1

XOR?

:)

Hmm, cần văn bản hơn ...

+0

XOR không tốt như vậy vì cùng một giá trị sẽ dẫn đến cùng một giá trị được mã hóa. Và các số nguyên "gần" cũng sẽ dẫn đến giá trị gần. (Trừ khi bạn sử dụng một XOR khác nhau cho mỗi hàng). – Thilo

+0

Do đó :) sau câu trả lời. – leppie

0

Có một vài hai sơ đồ mã hóa đường có sẵn trong Net.

Simple insecure two-way "obfuscation" for C#

Bạn có thể chuyển đổi các số nguyên để nó byte mảng tương đương hoặc chuyển đổi nó thành một chuỗi cơ sở-64 và mã hóa đó.

+0

Không ai trong số họ là TỪ int TO int, mặc dù. Đó là vấn đề chính. Trong bất kỳ sơ đồ hợp lý nào, kết quả sẽ dài bằng khóa. Đối với mã hóa Int to Int, bảng thay thế là giải pháp duy nhất tôi có thể đưa ra, và sẽ có 4 tỷ mục;) Hoặc một số bithifting (như XOR), nhưng hầu như không được tính là mã hóa. – TomTom

+0

Có. Vấn đề chính là "FROM int TO int". – Mike108

+0

Mike tại sao bạn lại làm vậy? Dữ liệu được mã hóa được coi là vô dụng để xem xét. Theo đó, tại sao bạn lại quan tâm đến loại kết quả được mã hóa là gì? –

4

Tôi xin lỗi nhưng tôi không thể thấy lý do để mã hóa số trong cơ sở dữ liệu. Nếu bạn muốn bảo vệ dữ liệu khỏi con mắt tò mò, chắc chắn SQL Server có bảo mật được tích hợp sẵn, đúng không?

Trong trường hợp đó, hãy bảo vệ cơ sở dữ liệu với bảo mật tiêu chuẩn của nó. Nếu không, có được một DBMS tốt hơn (mặc dù tôi sẽ ngạc nhiên nếu điều này là cần thiết).

Nếu bạn có bit thông tin từ bảng mà bạn muốn làm cho có sẵn (như một số cột nhưng không phải những người khác), sử dụng một cái nhìn, hoặc kích hoạt để cập nhật một bảng (ít bảo đảm) hoặc chuyển định kỳ vào cái bàn đó.

+0

Bạn có thể lấy các tệp cơ sở dữ liệu và kiểm tra nhị phân thô để biết thông tin có giá trị. Điều đó sẽ bỏ qua bảo mật tiêu chuẩn trừ khi toàn bộ cơ sở dữ liệu được mã hóa mà tôi tin rằng yêu cầu phiên bản Enterprise. Bạn có thể mã hóa các cột riêng lẻ với SQL Server nhưng sau đó khó sử dụng chúng với Entity Framework. –

+0

@Tôi có thể cho rằng các máy chủ quan trọng của bạn phải an toàn về mặt vật lý. Nếu không, bạn có thể DOS một công ty chỉ bằng cách đi bộ với họ. Tương tự như vậy, các đường dẫn mạng đến một máy chủ nên được bảo vệ như nhau để bạn không thể, ví dụ, telnet cho họ willy nilly. – paxdiablo

+0

Rõ ràng Sony đã mất 12.700 số thẻ ngân hàng không được mã hóa. –

0

Vâng, mỗi injective, surjective chức năng từ int đến int có thể được sử dụng như một cách để "mã hóa" một số nguyên.

Bạn có thể tạo một hàm như vậy bằng cách tạo một mảng ngẫu nhiên với 65536 mục không có mục nhập trùng lặp nào khi sử dụng f(i) = a[i]. Để "giải mã" int của bạn, bạn chỉ cần tạo một mảng khác với b[i] = x | a[x] = i.

Như những người khác đã đề cập, đây có thể không phải là những gì bạn thực sự muốn làm. =)

Chỉnh sửa: Xem nhận xét của Jim Dennis!

+0

Vấn đề với điều này là cùng một giá trị sẽ dẫn đến cùng một giá trị được mã hóa. Vì vậy, bạn vẫn có thể tìm thấy những người có cùng mức lương. – Thilo

+1

Bạn có thể làm điều đó với cột phụ có chứa muối. Nếu các giá trị muối đủ lớn (ví dụ 32 giá trị ngẫu nhiên) thì bạn sẽ loại bỏ gần như tất cả các va chạm. (Tôi thậm chí có thể có một ràng buộc UNIQUE trên cột muối, được thực thi bởi công cụ RDBMS). Nhìn chung ý tưởng ở đây vẫn vô lý ... nhưng về mặt lý thuyết ... –

Các vấn đề liên quan