cookies 登录的安全问题

oauth2.0

ssl也有必要.

应该没什么太大问题了吧。

大多session也是基于cookie。

如果是非浏览器客户端，或者oauth，每个访问都需要access_toke，其实原理跟cookie差不多。

现在所有的认证手段除硬件认证外，都是基于cookie的，怎么会不安全。但在cookie的设计上要防cookie盗用，并兼顾用户跟踪。

没有ssl的话可以考虑淘宝以前的做法，一段时间无用户活动可以提示用户重新登录

有效期 httponly 加密 就可以了

后端对重要操作二次询问密码，例如查看身份信息，改密码，加密保之类
如果什么操作都重要，那就不该cookies登录

我们是前端ajax提交到后台，保存到session中的。从来木有用过cookie，都是用session的

@jiaozi session 是哪来的？

@aiden0xz 有区别么。。。

@jiaozi session的id就是保存在cookie中的。。。。

@sujin190 cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案

cookie 和session 的区别：

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中

@jiaozi 然而 session 要通过 cookie 传递的亲……session id 是在 cookie 里的，id 所对应的 data 才是在服务器上..用着 session (基本)就得用 cookie..

JWT: http://blog.rainy.im/2015/06/10/react-jwt-pretty-good-practice/

@breeswish cookie是不用写的，用了session，自动在客户端生成的吧。就是觉得登陆信息就应该用session。

@irainy 木有专业前端，前后都做的伤不起呀。。。

@jiaozi 确实有不用 cookie 传递 session 的办法，可以用 HTTPS Session 传递 Session，可以用 ETags 借助浏览器缓存传递 session，可以用 URL 传递 session，然而 OAuth 以外 99% 以上的 session 都是通过 cookie 传递的…

TCP 自身是无状态的，总要有个地方「持久化记录」一个唯一标示符，浏览器提供的「可以让服务器在客户端保存一段信息以供后续使用」的这个功能叫做 Cookie。

不信你清空 v2ex 上的 cookie 试试..看看 session 是不是丢失了

@jiaozi typo：<del>TCP</del> HTTP 自身是无状态的

@jiaozi 安全上没什么区别，我既然能伪造cookie保存的登录信息伪造登录，当然也能伪造sessionid伪造登录，反正你要有个信息来源于客户端不是

@jiaozi 现在不是流行全栈吗:D

首先，cookie 与 session 是息息相关的，session的标识是通过 cookie 的固定 key获取，比如 session_id 或者 jsession_id 等等，现在很多框架都会帮你实现隐藏的 session 功能。但实际上，在标准的HTTP协议上，根本没有我们所谈论的 session，session 是基于 cookie 的一种HTTP状态维持实现(RFC2109)

其次，在很多精简的后端框架，压根是没有session这个东西，需要实现session，需要自己去写cookie，并且需要自己去序列化session信息保存，比如使用数据库，使用文件，使用缓存等等。而且写入cookie的key可以是你自己定义的任何值，比如 access_token、auth_token、abc或者任何你喜欢的

然后，最近我们做了一个项目，是完整的前后端分离，使用的方法是使用token验证，而且涉及到不同后端应用的反向代理，实现一个分布式的 session 不太现实，我们要求各后端应用的设计各自实现自己的类session状态维持，但实际上，这种设计是不合理的，http的优势反而是无状态。

最后，关于安全问题，除了增加无操作超时机制、多重验证的手段外，最能够防止 cookie 劫持的方法是使用 https。

希望以上信息对你有用。

建议session用redis来做，后面做负载也不用考虑session共享的问题

抱歉，没看清楚是网站，惯性以为是app的

session的数据是存放在服务端的，但是session ID是写在cookies的。
最简单提升安全度的方式自然是SSL，这样你的session ID就不会被人抓到了。

@Sight4
https可以防止cookie劫持，但是考虑极端一点，如果别人可以使用你的浏览器，把cookies记录下来，这样是可以伪造cookies进行登录的吧。如果session设置超时自动销毁还好，但是许多地方都有记住密码功能，用户状态是长期保存的，这样的网站如果伪造了cookies是可以一直保持登录的吧

大多数网站登录信息保存都和cookie相关，只是说看你登录信息如何保存了，自己想一套token验证机制用cookie实现还是比较安全的，遇到cookie劫持另说。 没有绝对安全的系统。

首先 session 没有比 cookie 安全。

下面都是一般的情况，安全要一步步来嘛：

现在基本都是 ajax 做基本的前后端分离，用 session 的话和以前没什么区别（所有的接口验证 session）。session_id 通过 cookie 传递（httponly），你网页上的恶意脚本无法获取到 session_id，但抓包的话还是可以看见 session_id，这是时候 https 就登场了，在证书安全的情况下别人是无法获取你的 cookie 的（至于能获取到什么这个不清楚，求大神赐教）。

楼主你是要在 cookie 里面存什么登录信息呀？一般的做法是存一个加密后的 “token”，这个 token 是有时效性的，可以在服务端反解出用户id/用户名。其实和 session 机制类似，这样做的好处就是统一认证接口，各个端、各个产品线、各个开发语言都可以用。当然还是不能防止别人复制你的 token 干坏事，请搜索关键词：CSRF 攻击。

cookie、session 的问题至少还可以说 10 年，并不是一句“cookie 保存在客户端，session 保存在服务端”能解释清楚的。

登录注册都交给后台 cookie也是后台设置 httponly 退出登录都是交给后台清cookie

@jiaozi 有个问题，你的session怎么和用户对应起来，不还是客户端的cookie中的某个值来找到对应的session？

看有些回复似乎对 cookie 和 session 概念不是很清楚，我的理解是 session 和 cookie 根本是两个不同层次的概念，可很多文章非要把这两放在一起对比来说混淆读者。

cookie 是与 http 协议和浏览器实现标准相关的一部分，cookie 和 http 头部的其它http头字段差不多，而 session 是服务器维持用户状态的一种机制，它对于 http 协议和浏览器来说是透明的，它们并不知道 session 的存在。

由于http是无状态的，必须采取一种机制来追踪用户状态，session 的概念是这个，session 可以用不同的方式来实现，对 web 来说绝大部分情况都是用 cookie 来实现的，也有一些小众做法是在 url 上加 session id，或者在页面里加上个隐藏表单，session 实现的本质都是一样的，请求必须带上一个标识用户的信息，只不过在大部分情况下，这个信息都放在 cookie 中。

一般情况下都是session要依靠cookie保持的，比如jsessionid的那个cookie，马德好多教材都不说明这个

可以看一下JSON Web Token这个解决方案

@Amit 能使用你的浏览器已经属于社会工程的安全入侵问题，也不是服务端的设计能控制得来；无论session还是cookie还是token，在实际生产中都会控制超时，https只是提升安全系数，不是杜绝安全隐患。安全不是一方做得万无一失就高枕无忧，就好像，银行安全系数再高，被别人偷看了密码还是能把钱取出来是一个道理

jiaozi 是来赚@的，大家绕道！ ：）

如同 @breeswish 所说，大部分session是需要cookie支持的，这也是最方便的一种。

你要这么想，淘宝、FaceBook、Google也还是用 Cookie 来保存用户状态...

@sujin190 为什么没有区别？你是指都是通过客户端传递某一种信息（cookie或者token）来是识别用户吗？ 你伪造的途径是什么？（通过破解用户密码？）不管怎么样用户都得通过用户密码登录，如果这些信息泄露了，不管用什么方式都在根本上解决不了这样的安全问题的。当然我们只能预防这种情况，比如提供密码复杂度，限制api访问频次 etc。采用 session（cookie）一般是基于浏览器的做法，采用token一般app用的比较多。