信息泄漏时代,如何让自己的密码更安全?

更新日期: 2019-06-01阅读: 1.7k标签: 安全

密码的重要性,相信大家都不言而喻。而密码泄漏或信息泄漏,经常是层出不穷地出现,令人防不胜防。所以,一个强大而复杂的密码是保证自己账户安全的第一步。为了防止信息泄漏,我们可以做些什么呢?

  • 密码足够复杂;

  • 每个平台密码都不一样,比如QQ,微信,邮箱等;

  • 定期更换密码。

那怎样的密码才算是比较可靠的密码?一般而言,一个密码至少12位字符,包含数字,包含大小写,包含特殊符号,不使用现有单词,即是一个比较复杂的密码。那你自认为比较安全的密码,是否真正的安全呢?这里良许介绍两个工具可以用来评估你的密码的安全性—— cracklib 和 pwscore 。


cracklib介绍

1. cracklib 的安装

cracklib 可以用来检测你的密码是否可靠,在大部分发行版里都可以直接安装这个工具。

对于 Fedora 系的发行版,可以使用 dnf 命令安装 cracklib:

$ sudo dnf install cracklib

对于 Debian/Ubuntu 系的发行版,可以使用 apt-get 命令安装:

$ sudo apt install libcrack2

对于 Arch 系统的发行版,可以使用 pacman 命令安装:

$ sudo pacman -S cracklib

对于 RHEL/CentOS 系的发行版,可以使用 yum 命令安装:

$ sudo yum install cracklib

对于 openSUSE 系的发行版,可以使用 zypper 命令安装:

$ sudo zypper install cracklib


2. cracklib 的使用

我们直接来看几个实例。

如果你的密码里包含了人名、地名,或者我们常用的单词,那么会被提示 it is based on a dictionary word :

$ echo "password" | cracklib-check
password: it is based on a dictionary word

Linux 下默认的密码长度是 7 个字符,如果你的密码长度小于 7 个字符,会被提示 it is WAY too short :

$ echo "123" | cracklib-check 
123: it is WAY too short

如果你的密码比较强壮,则会提示 OK :

$ echo "ME$2w!@fgty6723" | cracklib-check
ME!@fgty6723: OK


pwscore 介绍

我们使用 cracklib 工具只能判断一个密码是否安全,但具体也不知道它有多安全。而 pwscore 工具就能告诉你,你的密码强度可以打几分。

1. pwscore 的安装

同样地,对于大部分 Linux 发行版,可以直接安装 pwscore 工具。安装过程与 cracklib 类似,只需将 cracklib 改成 pwscore 即可。这里介绍 Debian/Ubuntu 系发行版的安装,其余的类似:

$ sudo apt install libpwquality

2. pwscore 的使用

同样直接来看几个实例。

与 cracklib 类似,如果你的密码里包含了人名、地名,或者我们常用的单词,那么会被提示 it is based on a dictionary word ;如果密码长度短于 7 个字符,会被提示 it is WAY too short 。

$ echo "password" | pwscore
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word

$ echo "123" | pwscore
Password quality check failed:
 The password is shorter than 8 characters

如果你的密码合乎规范,那么它就会给你打相应的分数:

$ echo "ME!@fgty6723" | pwscore
90


小结

虽然黑客有一万种窃取你的私人数据的方法,但一个强壮的密码是你保护你敏感数据的第一步。网络环境本身就不是 100% 安全,如果你再使用一个很容易玫破的密码,那下一个艳照门可能很快就会再次出现……


来自:良许Linux(微信号:liangxuxiansheng)
作者:良许  


链接: https://fly63.com/article/detial/3525

Web前端安全同样不可忽视,编写前端代码时保持安全意识

随着网络的普及,黑客进行网络攻击的手段越来也多,越来越复杂。前端的HTML、JavaScript、CSS、Flash等技术变成了前端攻击者和开发者的战场,网站安全问题也开始向前端倾斜。

AJAX请求真的不安全么?谈谈Web安全与AJAX的关系。

AJAX请求真的不安全么?AJAX请求哪里不安全?怎么样让AJAX请求更安全?本文包含的内容较多,包括AJAX,CORS,XSS,CSRF等内容,要完整的看完并理解需要付出一定的时间。

第三方 CSS 并不安全

第三方内容在其沙箱区域内具有强大的能力。如果你担心恶意用户诱使你的网站加载第三方资源,可以通过 CSP 用作防护手段,其可以限制加载图片,脚本和样式的来源。

WEB应用程序安全检查列表

检查页面隐藏或丢失的内容:检查webserver元数据文件,如:robots.txt, sitemap.xml,.DS_Store, .htaccess,检查搜索功能可能的注入或攻击方式,检查不同agent代理访问网站显示内容的是否一致

利用CSS注入(无iFrames)窃取CSRF令牌

要做到无iFrame,我将使用一种类似于之前我讨论过的方法:我将创建一个弹窗,然后在设置计时器后更改弹出窗口的位置。使用这种方法,我仍然可以加载受害者的CSS,但我不再依赖于受害者是否允许iFrame。

30 分钟理解 CORB 是什么

我当前的 chrome 版本是 v68,如果是 v66 或更低版本可能提示的警告信息略有不同。印象中只对 CORS 比较熟悉,CORB 是个什么鬼?好奇心迫使我想要了解一下它到底是什么,于是暂时把手头工作放下查了一些资料并花时间汇总了一下,就有了这篇文章

谈 target=‘_blank’的安全问题

大家都喜欢target=_blank, 因为新页面打开不影响原来的页面。但是这个存在安全问题, 由target=_blank打开的页面, 可以通过window.opener访问原来的窗口。遍可以简单的将网页导航到其他网站, 这就存在很多的安全隐患了, 比如钓鱼,这种问题解决起来也很简单, 在链接中加入rel=noreferrer noopener属性就可以了

Web安全测试检查单

Web安全测试检查单。上传功能:绕过文件上传检查功能,上传文件大小和次数限制。注册功能:注册请求是否安全传输,注册时密码复杂度是否后台检验,激活链接测试

一些安全相关的HTTP header

HTTP Strict-Transport-Security,简称为HSTS。X-Frame-Options:是否允许一个页面可在<frame>、<iframe>、<object>中展现的标记。X-XSS-Protection作用:防范XSS攻击。

第三方CSS安全吗?

第三方内容在其沙箱中具有很高的影响力。 虽然图像或沙盒iframe有着非常小的沙箱,但脚本和样式的作用范围却影响你的整个页面,甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源,可以使用CSP(内容安全策略)保证安全

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!