Android: Lưu tên người dùng và mật khẩu?

178

Nếu tôi muốn lưu trữ tên người dùng và mật khẩu sẽ được sử dụng trong ứng dụng Android, cách tốt nhất để làm điều đó là gì? Có phải thông qua màn hình tùy chọn (nhưng nếu người dùng bỏ lỡ điều này thì sao?), Hoặc bật lên một hộp thoại và hỏi người dùng về thông tin đăng nhập? Nếu vậy, tôi phải duy trì trạng thái cho ứng dụng. Làm thế nào tôi sẽ làm điều này?

android  authentication  storage  credentials 
— Huyền thoại
nguồn
4
stackoverflow.com/a/786588/1166727 Hãy xem @RetoMeier (Trưởng nhóm phát triển Android tại Google) nói gì về điều này.
— tony gil
1
Nếu bạn đang tìm kiếm cách an toàn nhất để lưu trữ thông tin đăng nhập. Hãy đọc câu trả lời này stackoverflow.com/a/20560574/730807
— Durai Amuthan.H
3
@ Cho phép bạn giải quyết vấn đề của bạn như thế nào?
— Erum 7/2/2015
@Legend, bạn có thể ném một số ánh sáng về tiết kiệm pwd trong Prefs sau khi mã hóa .. bởi vì tôi muốn ứng dụng của tôi để làm việc mà không có internet thì làm thế nào để tôi nhận được chìa khóa .. (coz tôi không thể lưu trữ khóa trên thiết bị)
— eRaisedToX
Bạn có thể sử dụng kho khóa cho Api +18. developer.android.com/training/articles/keystore
— Golnar

Câu trả lời:

115

Hầu hết các ứng dụng Android và iPhone tôi đã thấy sử dụng màn hình hoặc hộp thoại ban đầu để yêu cầu thông tin đăng nhập. Tôi nghĩ rằng việc người dùng phải nhập lại tên / mật khẩu của họ thường xuyên là rất khó khăn, vì vậy việc lưu trữ thông tin đó có ý nghĩa từ góc độ khả dụng.

Lời khuyên từ ( hướng dẫn dành cho nhà phát triển Android ) là:

Nói chung, chúng tôi khuyên bạn nên giảm thiểu tần suất yêu cầu thông tin đăng nhập của người dùng - để thực hiện các cuộc tấn công lừa đảo dễ thấy hơn và ít có khả năng thành công hơn. Thay vào đó hãy sử dụng mã thông báo ủy quyền và làm mới nó.

Nếu có thể, tên người dùng và mật khẩu không nên được lưu trữ trên thiết bị. Thay vào đó, hãy thực hiện xác thực ban đầu bằng tên người dùng và mật khẩu do người dùng cung cấp và sau đó sử dụng mã thông báo ủy quyền dành riêng cho dịch vụ trong thời gian ngắn.

Sử dụng AccountManger là tùy chọn tốt nhất để lưu trữ thông tin đăng nhập. Các SampleSyncAdapter cung cấp một ví dụ về cách sử dụng nó.

Nếu đây không phải là một tùy chọn cho bạn vì một số lý do, bạn có thể quay lại để duy trì thông tin đăng nhập bằng cơ chế Tùy chọn . Các ứng dụng khác sẽ không thể truy cập tùy chọn của bạn, vì vậy thông tin của người dùng không dễ bị lộ.

— Eric Levine
nguồn
40
Tôi sẽ nói rằng thật nguy hiểm khi duy trì thông tin mật khẩu như trong sở thích. Trên điện thoại đã root, có thể truy cập tệp tùy chọn của ứng dụng. Ít nhất bạn có thể làm là làm xáo trộn mật khẩu.
— Jayesh
51
Nếu ai đó có điện thoại của bạn và có thể root điện thoại, bạn sẽ không thể làm gì để giữ an toàn cho dữ liệu của mình. Nó không phải là một ý tưởng tồi để làm xáo trộn mật khẩu, nhưng nó không thực sự bổ sung thêm sự bảo vệ đó. Điều quan trọng hơn là có nhiều lớp bảo mật đã được tích hợp trong HĐH. Tất nhiên, bạn không muốn làm bất cứ điều gì ngu ngốc để phá vỡ các biện pháp đó. Có lẽ tốt hơn là sử dụng một hệ thống như OAuth và lưu trữ mã thông báo trên thiết bị thay vì tên người dùng và mật khẩu.
— Eric Levine
4
Nếu bạn sử dụng AccountManager(theo câu trả lời của tôi và @ Miguel theo cách vòng vo) và ai đó có được điện thoại GSM của bạn, họ sẽ cần tiếp tục sử dụng SIM của bạn để có quyền truy cập vào tài khoản của bạn, vì nó sẽ làm mất hiệu lực thông tin lưu trữ khi SIM thay đổi.
— Jon O
3
Xóa sạch tài khoản khi thay đổi SIP cách đây khá lâu, bởi vì nó rất ít ý nghĩa, đặc biệt là đối với những người có nhiều hơn một SIM. Chiến lược tốt hơn nếu điện thoại của bạn bị đánh cắp là truy cập trang tài khoản Google của bạn và thu hồi quyền truy cập cho thiết bị cụ thể.
— Nikolay Elenkov
2
"Sử dụng AccountManger là tùy chọn tốt nhất để lưu trữ thông tin đăng nhập." Tại sao?
— Lục
9

Bạn nên sử dụng Android lý Tài khoản . Đó là mục đích được xây dựng cho kịch bản này. Hơi cồng kềnh một chút nhưng một trong những điều nó làm là vô hiệu hóa thông tin đăng nhập cục bộ nếu thẻ SIM thay đổi, vì vậy nếu ai đó quẹt điện thoại của bạn và ném SIM mới vào đó, thông tin đăng nhập của bạn sẽ không bị xâm phạm.

Điều này cũng cung cấp cho người dùng một cách nhanh chóng và dễ dàng để truy cập (và có khả năng xóa) thông tin đăng nhập được lưu trữ cho bất kỳ tài khoản nào họ có trên thiết bị, tất cả từ một nơi.

SampleSyncAdOG (như @Miguel đã đề cập) là một ví dụ sử dụng thông tin đăng nhập tài khoản được lưu trữ.

— Jon O
nguồn
3
Trường hợp được ghi lại rằng AccountManager sẽ "vô hiệu hóa thông tin đăng nhập cục bộ nếu thẻ SIM thay đổi"?
— Eric Levine
Đó không phải là tôi biết. Tuy nhiên, đó là điều mà tôi đã tin / chấp nhận / hiểu sau khi một số người dùng ứng dụng của tôi gặp sự cố xác thực sau khi hoán đổi SIM.
— Jon O
1
Tôi không thấy nó trong mã JavaDocs hoặc AccountManager. Nghe có vẻ như là một tính năng tốt, thật tuyệt khi xác minh và hiểu chi tiết.
— Eric Levine
2
Theo @NikolayElenkov, tính năng thay đổi thẻ SIM không hợp lệ đã bị xóa.
— ThomasW
2
@ThomasW bạn có một trích dẫn cho điều đó? Nó sẽ là tuyệt vời để có được một câu trả lời dứt khoát của một số loại.
— Jon O
8

Tôi nghĩ cách tốt nhất để bảo mật thông tin đăng nhập của bạn là trước tiên nghĩ đến việc lưu trữ Mật khẩu bằng mã hóa trong tệp account.db, thứ không thể có sẵn trong các thiết bị chưa root và trong trường hợp thiết bị đã root, hacker phải cần khóa để giải mã nó

Tùy chọn khác là thực hiện tất cả xác thực của bạn giống như cách Gmail đang thực hiện. sau lần xác thực đầu tiên với máy chủ Gmail. bạn đã nhận được Mã thông báo xác thực sẽ được sử dụng trong trường hợp mật khẩu của bạn. mã thông báo đó sẽ được lưu trữ trong văn bản thuần túy. Mã thông báo này có thể sai trong trường hợp bạn thay đổi mật khẩu từ Máy chủ.

tùy chọn cuối cùng tôi khuyên bạn nên kích hoạt Xác thực 2 yếu tố & tạo Mật khẩu riêng cho thiết bị cho thiết bị của mình. Sau khi mất thiết bị, tất cả những gì bạn cần là vô hiệu hóa thiết bị đó.

— Riz
nguồn
2
Bạn có thể đăng một nguồn cho biết, tài khoản đó được mã hóa không? Hay bạn nói rằng mật khẩu cụ thể nên được mã hóa?
— Michał K
1
@Riz, nơi lưu trữ khóa để mã hóa sau đó ... vì ứng dụng của tôi hoạt động mà không có Internet, vì vậy không thể lấy nó từ mạng
— eRaisedToX
2

Với phần cứng và API vân tay mới (Android 6.0), bạn có thể làm điều đó như trong ứng dụng mẫu github này .

— Zlatko
nguồn
8
Dự án mẫu được tham chiếu tạo một khóa trong Cửa hàng khóa Android và sử dụng nó để tạo mật mã để mã hóa mật khẩu. Mật khẩu và mật mã được mã hóa được lưu trữ dưới dạng các chuỗi được mã hóa base64 trong các tùy chọn chia sẻ. Sau khi xác thực dấu vân tay thành công, khóa bí mật được lấy từ Cửa hàng khóa Android và được sử dụng với mật mã được giải mã để giải mã mật khẩu được giải mã.
— mjwheat
@mjwheat điều này rất hữu ích để hiểu những gì đang diễn ra trong ví dụ. Cảm ơn! Một lỗi đánh máy nhỏ: "... để giải mã mật khẩu được mã hóa."
— muetzenflo
2

Chúng được xếp theo thứ tự khó khăn để phá vỡ thông tin ẩn của bạn .

  1. Lưu trữ trong Cleartext

  2. Lưu trữ được mã hóa bằng khóa đối xứng

  3. Sử dụng kho khóa Android

  4. Lưu trữ được mã hóa bằng các khóa bất đối xứng

nguồn: Nơi tốt nhất để lưu mật khẩu trong ứng dụng Android của bạn

Bản thân Keystore được mã hóa bằng mã pin / mật khẩu khóa riêng của người dùng, do đó, khi màn hình thiết bị bị khóa, Keystore không khả dụng. Hãy ghi nhớ điều này nếu bạn có một dịch vụ nền có thể cần truy cập vào các bí mật ứng dụng của bạn.

nguồn: Đơn giản sử dụng Kho khóa Android để lưu trữ mật khẩu và thông tin nhạy cảm khác

— Dmytro Melnychuk
nguồn
1

Thông tin tại http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html là một cách tiếp cận dựa trên thực tế, nhưng "sử dụng-ẩn-android-apis". Đó là điều cần xem xét khi bạn thực sự không thể lưu trữ thông tin đăng nhập / mật khẩu cục bộ trên thiết bị.

Tôi cũng đã tạo ra một ý chính đã làm sạch ý tưởng đó tại https://gist.github.com/kbsriram/5503519 có thể hữu ích.

— kbs
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.