强制实施密码策略

强制实施密码策略

How many passwords do you use for online accounts? I have 250. That’s a conservative estimate and doesn’t include a plethora of hosting, database and SSH passwords.

您使用多少个在线帐户密码？ 我有250个。这是一个保守的估计，其中不包含过多的托管，数据库和SSH密码。

Despite using management tools such as KeePass, it’s difficult to use different passwords for every site — and I certainly don’t change them as often as I should. Even then, I forget what I’ve used on specific sites. Logging in is often a matter of clicking “forgotten password”, hitting an email link, entering a new password and finally gaining access.

尽管使用了诸如KeePass之类的管理工具，但很难为每个站点使用不同的密码-而且我当然不会像我应该的那样经常更改密码。 即使这样，我也忘记了我在特定网站上使用过的内容。 登录通常只需单击“忘记密码”，单击电子邮件链接，输入新密码并最终获得访问权限。

The average user has a couple of easily-remembered passwords for every account. There’s no guarantee every one of those sites has implemented good security measures. Perhaps passwords are stored in plain text or accessible to their staff, developers, database administrators or those working at their hosting company. Could your banking account be accessed just because you used the same credentials at dodgysite.com?

一般用户每个帐户都有几个容易记住的密码。 不能保证所有这些站点都已实施良好的安全措施。 密码可能以纯文本格式存储，或者可供员工，开发人员，数据库管理员或托管公司的人员访问。 是否可以仅由于在dodgysite.com上使用了相同的凭据而访问银行帐户？

We’re using the same ID and password mechanisms we implemented at dawn of the web. But a password backlash has begun. Passwordless logins have been proposed by developers such as Justin Balthrop and implementations have arrived, e.g. passwordless.net for Node.js. The main argument: passwords are obsolete because we all have secure email and mobile SMS accounts.

我们使用的是与网络黎明时相同的ID和密码机制。 但是密码抵制已经开始。 诸如Justin Balthrop之类的开发人员已经提出了无密码登录，并且已经实现，例如Node.js的passwordless.net 。 主要论点： 密码已过时，因为我们都有安全的电子邮件和移动SMS帐户 。

Passwordless login uses the following process:

无密码登录使用以下过程：

The user accesses a website and enters their email address (or mobile number).

用户访问网站并输入其电子邮件地址(或手机号码)。 A token (cookie) is sent to the device. A unique authentication code is generated and stored on the server then sent within a link to the user by email (or SMS).

令牌(cookie)被发送到设备。 生成唯一的验证码并将其存储在服务器上，然后通过电子邮件(或SMS)在链接内发送给用户。 The user has a limited time to click that link — perhaps ten minutes. When clicked, the existing token and authentication code are verified to ensure the same user is accessing. The user is then logged on and a session is started using a long-term token.

用户单击链接的时间有限-可能只有十分钟。 单击后，将验证现有令牌和身份验证代码，以确保访问同一用户。 然后，用户登录并使用长期令牌启动会话。 The user does not need to repeat the process unless they log out, switch browser, do not access the system for a specific duration or want to use another device.

除非用户注销，切换浏览器，在特定持续时间内不访问系统或想要使用其他设备，否则用户无需重复该过程。

In essence, it’s a similar process to resetting your password — which you would possibly have had to do anyway. The benefits include:

从本质上讲，这与重置密码的过程类似，无论如何您都可能必须这样做。 好处包括：

There’s no need for clever hardware or biometrics — the user just needs an email address or SMS number. That’s far more likely than having a Google, Twitter or Facebook account which can thwart those using OAuth providers.

不需要聪明的硬件或生物识别技术-用户只需要一个电子邮件地址或SMS号码。 这比拥有可以阻止使用OAuth提供商的Google，Twitter或Facebook帐户的可能性大得多。 You need never manage passwords again. There’s nothing for the user to invent, reuse, note down or reset. Support staff are freed from daily grind of account management duties.

您无需再管理密码。 用户无需进行任何发明，重用，记下或重置操作。 支持人员无需承担日常的帐户管理职责。 The user requires a valid email to log in so the usual registration and email validation shenanigans are avoided.

用户需要有效的电子邮件登录才能避免常规注册和电子邮件验证的手段。 No password is ever stored or sent. It cannot be guessed or hacked. Someone could grab your database and intercept HTTP traffic or email messages — they’d still have difficulty logging in.

永远不会存储或发送密码。 它不能被猜测或被黑客入侵。 有人可以抓住您的数据库并拦截HTTP流量或电子邮件-他们仍然难以登录。 There’s less code to deploy. Login forms have one field and security management is minimal.

部署的代码更少。 登录表单只有一个字段，并且安全管理很少。

Going passwordless is not a magic solution appropriate to every application. System developers will need to consider a number of issues…

无密码并不是适用于每个应用程序的神奇解决方案。 系统开发人员将需要考虑许多问题……

User Expectations I’m yet to use a passwordless system in the wild. While it shouldn’t be a difficult experience, few users will expect it. That could lead to additional support calls in the early days of deployment.

用户期望我尚未在野外使用无密码系统。 虽然这不是一个艰难的体验，但很少有人会期望它。 在部署初期，这可能会导致其他支持电话。

Logging on Takes Longer Despite time savings in password management, passwordless login could be annoying. It’s impossible to save credentials in the browser so you can never login automatically. Often-used applications such as social networks and large online stores would avoid going passwordless.

登录花费更长的时间尽管节省了密码管理时间，但无密码登录可能很烦人。 无法在浏览器中保存凭据，因此您永远不会自动登录。 诸如社交网络和大型在线商店之类的常用应用程序会避免使用无密码的方式。

It’s Not Suited to All Applications Passwordless login would be difficult to implement on a webmail client! In addition, you wouldn’t want your bank handing password security to a third-party.

并非适合所有应用程序无密码登录将很难在Webmail客户端上实现！ 此外，您不希望银行将密码安全性交给第三方。

Email Hacking If someone hacks your email account they have gain access to all your passwordless systems. It would fairly easy to discover which systems you’re using just by examining the deleted items folder. That said, if someone hacks your email account they can also reset your password at many sites using standard authentication.

电子邮件黑客攻击如果有人黑客您的电子邮件帐户，他们将有权访问您所有的无密码系统。 仅通过检查已删除邮件文件夹，就很容易发现正在使用的系统。 也就是说，如果有人入侵了您的电子邮件帐户，他们还可以使用标准身份验证在许多站点上重置您的密码。

However, a large number of applications could benefit from a passwordless approach. You could certainly consider it if your system is used fairly infrequently and has minimal security implications, e.g. forums, support ticketing, analytics, monitoring, reporting systems etc.

但是，无密码方法可以使大量应用程序受益。 如果您的系统很少被使用并且对安全性的影响最小，那么您当然可以考虑一下，例如论坛，支持票务，分析，监控，报告系统等。

Passwordless isn’t for everyone. Implementation libraries are scarce and some companies would be nervous about becoming an early adopter. But I like the idea and investigating the viability for a system I’m working on. I’ll let you know how it turns out.

无密码并非适合所有人。 实施库很稀缺，一些公司对于成为早期采用者会感到紧张。 但是我喜欢这个主意，并且正在研究我正在开发的系统的可行性。 我会让你知道结果如何。

Would you go passwordless?

你会不用密码吗？

翻译自: https://www.sitepoint.com/implement-passwordless-login/

强制实施密码策略

相关资源：jdk-8u281-windows-x64.exe