2008-11-04 30 views
8

Khi hỗ trợ ứng dụng web mới trong môi trường doanh nghiệp, thường cần phải đăng nhập với tư cách là người dùng cụ thể để chẩn đoán một vấn đề thực sự hoặc nhận thức mà họ đang gặp phải. Hai vấn đề đối lập áp dụng ở đây:Làm cách nào để bạn hỗ trợ ứng dụng web có mật khẩu băm hoặc mã hóa?

  1. Thực hành tốt nhất là sử dụng băm hoặc mã hóa mật khẩu, không rõ ràng văn bản. Đôi khi, có một SSO của bên thứ ba (đăng nhập một lần) ở giữa. Không có cách nào để lấy lại mật khẩu của người dùng. Trừ khi người dùng cung cấp nó (không được khuyến khích), không có cách nào để đăng nhập với tư cách người dùng đó.

  2. Nhiều ứng dụng web có cá nhân hóa và ủy quyền phức tạp. Những người dùng khác nhau có vai trò khác nhau (quản trị viên, người quản lý, người dùng) với các quyền khác nhau. Đôi khi, người dùng chỉ có thể xem dữ liệu của họ - khách hàng hoặc nhiệm vụ của họ. Một số người dùng có quyền truy cập chỉ đọc, trong khi những người khác có thể chỉnh sửa. Vì vậy, lượt xem của từng người dùng ứng dụng web là duy nhất.

Giả sử trong môi trường doanh nghiệp, không thể đến bàn của người dùng hoặc kết nối trực tiếp với máy của họ.

Bạn xử lý tình huống này như thế nào?

Chỉnh sửa: Tôi muốn nhắc lại rằng trong một tổ chức tài chính lớn hoặc công ty Fortune 500 điển hình với hàng trăm nghìn nhân viên trong cả nước và trên thế giới, không thể cho một nhà phát triển đơn thuần trong một số đơn vị CNTT có thể truy cập trực tiếp vào máy của người dùng. Một số trong số đó là các ứng dụng web công khai được khách hàng sử dụng (chẳng hạn như ngân hàng trực tuyến và giao dịch chứng khoán). Và, nhiều trong số đó là các ứng dụng mạng nội bộ dựa vào Active Directory hoặc SSO, nghĩa là các thông tin đăng nhập của người dùng giống nhau đối với nhiều ứng dụng. Tôi cảm ơn tất cả các bạn đã đề xuất; một số có thể rất hữu ích trong các loại môi trường khác.

Trả lời

19

Một số ý tưởng này gây bất tiện cho người dùng, bằng cách buộc họ thay đổi mật khẩu của họ hoặc bằng cách chiếm máy tính để bàn của họ để gỡ lỗi phiên.

Ý tưởng của Markc là tốt nhất: tăng cường logic xác thực của bạn để cho phép siêu người dùng đăng nhập với tư cách người dùng cụ thể bằng cách không cung cấp bằng chứng xác thực của người dùng.

tôi đã thực hiện nó như thế này trong (python pseudo-ish) qua:

if is_user_authenticated(username, userpassword): 
    login the user 
else if ':' in userpassword: 
    supername, superpassword = userpassword.split(':') 
    if is_superuser_authenticated(supername, superpassword): 
     login the user 

Nói cách khác, nếu tên người dùng và mật khẩu không xác thực, nếu mật khẩu có dấu hai chấm, sau đó nó thực sự là tên người dùng quản trị và mật khẩu quản trị được nối bằng dấu hai chấm, vì vậy hãy đăng nhập với tên người dùng nếu họ là tên người dùng và mật khẩu quản trị thích hợp.

Điều này có nghĩa là bạn có thể đăng nhập với tư cách người dùng mà không biết bí mật của họ và không làm họ bất tiện.

+0

Có, tôi nghĩ điều này nghe có vẻ khả thi. Để tiếp cận ứng dụng, tất cả người dùng "quản trị viên khách" hợp lệ có thể phải được tạo. Khi người dùng đó đăng nhập, họ sẽ nhận được một giao diện người dùng đặc biệt để nhập tên người dùng (và các thông tin có thể khác sẽ đến từ một nơi nào đó như Active Directory, chẳng hạn như Group hoặc Dept). – DOK

+0

Không cần giao diện người dùng đặc biệt. Nhập tên người dùng vào trường tên người dùng và tên người dùng: siêu vào trường mật khẩu. –

+0

+1 Tôi nghĩ điều này thật tuyệt vời vì nó cho phép bạn thực sự đăng nhập với tư cách là người dùng cụ thể (thay vì mô phỏng họ hoặc bất kỳ thứ gì). Vì vậy, nó sẽ loại bỏ "Tôi không thể tái tạo vấn đề", hoặc ít nhất là xác nhận nếu nó xuống đến môi trường địa phương của họ (ví dụ: trình duyệt, v.v.). –

1

Quản trị viên có thể thay đổi mật khẩu của người dùng. Thay đổi mật khẩu cho người dùng thành thứ bạn biết. Sau đó, bạn có thể đăng nhập với tư cách người dùng đó.

Yêu cầu người dùng đặt lại mật khẩu của họ sau khi bạn hoàn tất gỡ lỗi.

+4

Đây là bất hạnh: tại sao nên người sử dụng được bất tiện vì bạn đã gỡ lỗi? –

+0

Đúng. Nếu có thể 'sao chép' tài khoản người dùng và sử dụng tài khoản đó thay vào đó, người dùng cuối có thể không gặp bất tiện. Điều này có thể hoặc có thể không khả thi. Ngoài ra, nếu bạn có thể sử dụng tài khoản 'debuguser' để xem vấn đề, điều đó cũng có thể thích hợp hơn - nhưng nó có thể không tái tạo. –

1

Thông thường bằng một số loại phần mềm điều khiển từ xa có thể được sử dụng để xem máy tính để bàn của chúng. Nếu họ đang ở trên một máy chủ đầu cuối Windows, thì các công cụ quản trị được tích hợp sẵn có thể được sử dụng cho điều đó. Nếu không tôi sẽ sử dụng một cái gì đó như VNC trên một mạng nội bộ, hoặc một dịch vụ bên ngoài như LogMeIn (http://www.logmein.com/).

0
  1. bạn có thể có một môi trường thử nghiệm, nơi có một vết cắt thường xuyên của dữ liệu trực tiếp sao chép vào (rõ ràng vệ sinh để đáp ứng bất kỳ vấn đề an ninh hay bảo vệ dữ liệu). Một người dùng tương tự trong thiết lập với một trong những vấn đề có thể được sử dụng để khắc phục sự cố hoặc thực sự là rất người dùng nếu điều này được cho phép.

  2. Sử dụng ứng dụng khách máy tính để bàn từ xa như được đề cập trong các câu trả lời khác, nhưng điều này có thể không thực tế đối với bạn. Nếu bạn có các quyền này trong miền, tôi đã nghe nói về việc xử lý lỗi ngay cả khi thực hiện một screencrape và bao gồm cả điều này trong nhật ký! nhưng điều này nghe có vẻ hơi lạ với tôi.

  3. Bạn có thể có công cụ quản trị để sao chép người dùng vào tài khoản demo không?

5

Đối với các ứng dụng web của chúng tôi, chúng tôi sử dụng quy trình thiếu cụm từ tốt hơn được xác định là 'chiếm đoạt' tài khoản của người dùng.

Về cơ bản, quản trị viên có thể 'chiếm đoạt' tài khoản của người dùng bằng một lần nhấp nút đơn giản. Trong mã, bạn chỉ cần sử dụng một mã định danh duy nhất (id người dùng hoạt động trong một môi trường kém an toàn hơn), sau đó thiết lập các thông tin cần thiết trong phiên để họ có thể làm việc trong hồ sơ của người dùng đó. Đối với một môi trường an toàn hơn, bạn có thể sử dụng một băm duy nhất cho mỗi người dùng.

Để đảm bảo rằng phương pháp hijack này là an toàn, trước tiên nó luôn xác minh rằng yêu cầu đang được thực hiện bởi một quản trị viên được chứng thực với các quyền thích hợp. Bởi vì điều này trở nên cần thiết cho phiên của quản trị viên bị chiếm đoạt hoặc cho các thông tin đăng nhập xác thực của họ để được chụp để ai đó khai thác chức năng chiếm quyền điều khiển trong ứng dụng.

+0

Chúng tôi cũng sử dụng phương pháp này, đặc biệt quan trọng khi một số người dùng của chúng tôi không có tên người dùng (họ sử dụng SSO thay thế). Nó chỉ đơn giản sử dụng cùng một hệ thống phiên làm tên người dùng/mật khẩu và các phương thức đăng nhập SSO, nhưng từ một nút trong trang hồ sơ của tài khoản bị xâm nhập. Chúng tôi đã bị ép buộc phải cung cấp cho một số nhân viên hỗ trợ điện thoại của chúng tôi quyền chiếm đoạt tài khoản người dùng và họ đã nhận thấy nó vô giá. – eswald

2

Tôi có 4 ý tưởng. Trong khi tôi đang gõ 3 trong số họ đã được gợi ý (vì vậy tôi bỏ phiếu tán chúng)

Ngôn ngữ địa phương trên ý tưởng 3 - mạo danh:

Để làm điều này là "giống hệt nhau càng tốt" để đăng nhập bình thường với những thay đổi mã số tối thiểu, bạn có thể thêm khả năng mạo danh trực tiếp khi đăng nhập bằng cách cung cấp thông tin đăng nhập Quản trị cộng với tên người dùng thay thế, ví dụ: đăng nhập với tư cách Admin: user, adminpassword. Hệ thống sẽ xử lý chính xác điều này khi đăng nhập với tư cách người dùng với userpassword.

Ý tưởng 4: Bạn có thể truy cập kho lưu trữ mật khẩu không? Nếu vậy, tạm thời thay thế băm của người dùng bằng băm của một mật khẩu đã biết. (mật khẩu thường được lưu trữ trực tuyến trong cơ sở dữ liệu. Công cụ truy vấn SQL có thể thực hiện hoán đổi)

+0

Tôi thích nơi bạn đang đi với # 3, và Ned đã khuếch đại trên đó. – DOK

0

Giải pháp mà chúng tôi đã sử dụng trong các ứng dụng web của chúng tôi là yêu cầu authN/authZ trả lại người dùng mong muốn làm người dùng hiệu quả. Chúng tôi làm điều này bằng cách có một tính năng quản trị để thiết lập một masquerade, và sau đó khi chúng tôi yêu cầu hiện đang đăng nhập người dùng (CURRENT_USER), chúng tôi xử lý các masquerade:

def current_user_with_effective_user 
    if masked? 
     current_user_without_effective_user.masquerade_as 
    else 
     current_user_without_effective_user 
    end 
    end 
    alias_method_chain, :current_user, :effective_user 
Các vấn đề liên quan