怎么做能提供RESTful的安全性？ - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Programming - 葵花宝典

怎么做能提供RESTful的安全性？

怎么做能提供RESTful的安全性？# Programming - 葵花宝典

h*e2015-04-01 07:04

1 楼

>45K miles in three accounts (mine, my wife's and my daughter's) United's
Mileage Plus. Need to make a trip
next month but was told 0 miles available. Does anybody have an idea about
how to get part of it back?
I've talked to them, but they didn't agree to honor anything.
Thx!

n*m2015-04-01 07:04

2 楼

“原来前辈已经知道螟虫之母的事情了，若是如此的话，晚辈自然没有什么好隐瞒
的。”枯瘦老者先是一怔，但马上神色一松的回道。
“有关螟虫之母之事，多年前我等就知道一些消息了。这一次出世，其实也正为了
此次大劫而来。但对圣界如今情形还不太清楚，所以才会向你这位一城之主打听一二的
。现在将你知道的事情，全都说出来吧。”韩立淡然的问道。
”是，前辈！晚辈知道的消息也不算太多，并且也是近十来年才真正知道的。晚辈
所知的是，现在圣界出现的这些螟虫，其实就是普通魔虫感染了螟虫之母从封印中泄露
出的一些气息后，才变异成这般凶恶摸样的。这些普通魔虫一旦变成螟虫后，不但实力
大增，繁殖能力更是一下激增数十倍以上。否则这些螟虫也不会越灭越多，最终成了圣
界的心腹大患。”
老者说到这里，口中话语略微顿一下后，在韩立注视下，又马上惶恐的继续说道：
“根据我得到的消息，三位始祖大人和其他圣祖前辈，的确都该在始印之地应对那
头螟虫之母。开始时，似乎情形不错，在其他一些异界强者的帮助下，螟虫之母的封印
一直在持续加固中，将其重新封印住是大有可期的样子。但是从二十多年前起，始印之
地却忽然和外界失去了联系，再无任何消息从中传出了。现在里面究竟是何种情形，却
是谁也不知的事情。”
“失去了联系！以元魇他们的始祖实力，外加还有这么多同阶帮手，这怎么可能！
没有人再去查看一下真实情形吗？”韩立眉头一皱后缓缓问道。
“等有人发现始印之地失去联系时，已经迟了。在始印之地四周，不知何时出现了
数之不尽的螟虫群，不但将离附近几座城镇彻底占龘据了，其中还出现了非常强大的高
阶螟虫据说实力不在一般合体之下，外人根本无法闯过虫海，重新进入始印之地中。”
老者诺诺的回道。
“合体等阶的螟虫！以螟虫之母的可怕，出现此等阶的高级螟虫，这倒并不是太奇
怪的事情。但外界不是还有一些未进入始印之地的圣祖道友吗，他们难道坐视此事不管
？”韩立略一沉吟后，又问了一句。
“回禀前辈，其他圣祖前辈是何态度晚辈是不清楚了但的确未曾听闻有其他圣祖前
辈去查看始印之地的消息传出。至于是何缘由，却不是晚辈这样的小城主可以知道的了
。”枯瘦老者愁眉苦脸的回道。
“有些意思了。看来其他圣祖道友是知道些什么，否则不会到现在还没有采取行动
的。现在尚留的圣祖中，哪一位离黑葫城更近一些？”韩立冷笑了一声，但马上问了一
句。
“离本城最近的圣祖，那就是万花山脉的邪莲圣祖了。这位前辈在三年前才刚刚出
手过一次，将其山脉附近的螟虫群全都扫荡一空过。”这一次，枯瘦老者倒没有迟疑什
么直接恭声的回道。
“邪莲圣祖？万花山脉在什么地方，你可有那边地图？”韩立点点头，看似随意的
问道。
“有，晚辈当年曾经亲自去万花山求见过邪莲前辈，相关地图留有备份的。”枯瘦
老者赔笑的回道，并立刻识趣的从身上取出一块不大石片双手捧了过来。
韩立单手一招，就将石片摄到了手中，用神念匆匆一扫后才露出一丝笑意的回道：
0
回复
1楼
2012-10-24 00:03
无__可取代
真仙降临
12
“道友的回答，我很满意。其他就没什么事情了，你去忙自己的事情去吧。”
“是，那晚辈先告退了。”老者心中一松，躬身一礼的徐徐倒退数步后，才转身向
下方飞落而去。
一群早就等候在附近的高阶魔族立刻远远的迎了上来，簇拥着老者向城中隐没而去
了。
“我们走吧去那万花山脉见见那位邪链圣祖去！”韩立往下方黑葫城扫了一眼后，
平静的说道。
银月和蟹道人自然没有反对的意思。
下面，韩立抬首放出一只黑乎乎的四方魔族飞车。
三人飞到上面后，当即化为一道黑虹的破空而走。
一个月后，韩立等人身影出现在一片葱葱绿绿、几乎和人界山脉并无二致的山脉上
空。
“这就是万花山脉！景色倒是秀美异常，那位邪莲圣祖还真是找了一处好地方。不
过这位圣祖居住在山脉何处？”银月站在韩立身后，四下一阵扫视后，笑吟吟的说道。
“地图上标明了那位邪莲圣祖的居住处，是一座叫朝天峰的地方，就在这片山脉的
中心处。”韩立一笑的回道。
“哦，若是这样的话。这位邪莲圣祖倒是不难寻到的。不过我惘的匆忙，还没有来
及打听这位邪莲圣祖是怎样之人，有何大神通，不会是异常的凶恶吧！”银月眼珠转了
一转后，嫣然一笑的说道。
“嘿嘿，就算再凶恶之人，也要从其口中弄清楚始印之地到底出了何事。如此一来
，我等才知道下一步如何走才是最稳妥的。当然，要是能直接弄清楚莫简离和傲啸两位
前辈的下落，自然更好了。“韩立徐徐的说道，胸有成竹的摸样。
银月一听自己祖父的名字，脸上一丝担心之色闪过，但还是默然的点点头。
“走吧。这万花山脉不算太大，到那朝天峰不会花费太长时间的。”
韩立不再多说什么，袖子一抖，就化为一道青虹的破空而走。
银月和蟹道人也遁光一起的紧随而后。
数个时辰后，山脉中原本连绵不断的群峰一分后，一座高白色巨峰一下高耸入云的
出现在韩立三人眼前。
此峰足有数万丈之高，并且从山腰间开始，上半截全都被白茫茫冰雪覆盖，下半截
则被一层层黑色雾气笼罩其中，里面狂风滚滚，并隐约有鬼哭狼嚎之声发出。
“这就是朝天峰，还真有些邪门的样子。”
韩立三人在离巨峰十余里远地方停下了遁光，银月明显被此峰诡异摸样吓了一跳。
“不过是区区的障眼之法，对普通魔族有用，但对我和蟹兄来说，又怎能真欺瞒过
去！”韩立目中蓝芒微闪的打量了山峰几眼后，却露出一丝笑容的说道。
“障眼之法？”银月美目睁得的老大，上下再仔细打量了远处山峰好几遍后，仍未
看出什么问题来的摸样。
韩立见此轻笑一声，忽然单手一掐诀，眉宇间一团黑气一凝，第三颗竖目顿时显现
而出，
下一刻，韩立一声低喝，一道拇指粗细的晶色光柱一喷而出，一闪即逝下，就没入
远处虚空中不见了踪影。
“轰”的一声巨响，一股强烈波动顿时从远处滚滚而来。
数里外的虚空，一下水面般的荡漾而开，画面一个模糊后，所有景色骤然间一变。
原本巨大山峰竟一下凭空不见。
取而代之的，却是一片百里大的盆地，中心处，则有一座数千丈高的秀丽山峰。
此峰和先前巨峰不同，表面遍布各种奇花异草，并被一层五色光晕笼罩其中，显得
十分艳丽。
韩立目光却被山峰顶部的一座宫殿，一下吸引住了。
这座宫殿占地不过数亩，通体翠绿异常，竟似全是用新鲜树木搭建而成一般。
“这才是正的朝天峰！”银月愣了好一会儿，才有些难以置信的喃喃道。
韩立听了这话微微一笑，正想开口回复些什么时，远处那座秀丽山峰中，忽然一个
冷冷的女子声音传了出来：
“哪位道友大驾光临我朝天峰，邪莲未能亲自出去远迎，还望多多见谅。”
话音刚落，翠绿宫殿中一道翠虹冲天而起，一个盘旋后蓦然向韩立这边激龘射而来。
只是几个闪动，韩立等人前方十几丈外处，遁光一敛，一名神色冰冷的绿色宫装女
子，一下现身而出。
韩立目光往此女面上一扫后，却面色一变，一下失声而出：
“宝花？不对，你不是宝花！”
这绿色宫装女子面容赫然和宝花极为相似，但再仔细一望，却发现此女神情太过阴
冷，和宝花又截然不同的样子。
“三位道友不是圣界之人吧。否则怎会将妾身和‘宝花，差点弄混了。”绿色宫装
女子听闻韩立之言，目中冷光一现，但再仔细一打量韩立和蟹道人几眼后，神色微微一
缓的言道。
银月一听女子此言，脸色顿时为之一变。
韩立面上惊容却瞬间恢复如初了，上下打量了宫装女子两眼后，却淡淡的问了一句：
“我三人既然直接来见道友，原本就没有想隐瞒自己真正来历的意思。倒是邪莲道
友让在下吃惊不小，不知和宝花道友又是如何称呼的？”
“宝花是在下的同胞姐姐，不知此事的大乘存在，恐怕也只有你们这些异界强者了
。”绿色宫装女子重新恢复阴沉表情的说道。
“原来如此，怪不得道友和宝花面容如此酷似了。不过我等的来意，邪莲道友应该
也清楚几分吧。”韩立不出预料的点点头，但又似笑非笑的问了一句。
“你们也是为始印之地的事情来的吧。”绿色宫装女子沉吟了好一会儿，才有些异
样的缓缓说道。（未完待续。如果您喜欢这部作品，欢迎您来起点◤起点首发◢投推荐
票、月票，您的支持，就是我最大的动力。）

i*h2015-04-01 07:04

3 楼

dell 600m
带了dell wireless WLAN 1350 WLAN Mini-PCI card
可是什么网都看不到(家里有无线router, 其它机器接网正常)
在device manager里说网卡工作正常
请问是个什么问题? 有解么?
谢谢

s*y2015-04-01 07:04

4 楼

在企业级应用中，iOS和Java之间用RESTful通信，如果想提高安全性，用什么比较好？
OAuth是不是一种选择？还有其他的吗？

w*e2015-04-01 07:04

5 楼

花钱可以弄回来，不过不值：
http://faq.ua2go.com/al/12/1/article.aspx?aid=1322&tab=browse&bt=4nb&r=0.6531615

about

【在 h*****e 的大作中提到】

: >45K miles in three accounts (mine, my wife's and my daughter's) United's
: Mileage Plus. Need to make a trip
: next month but was told 0 miles available. Does anybody have an idea about
: how to get part of it back?
: I've talked to them, but they didn't agree to honor anything.
: Thx!

c*i2015-04-01 07:04

6 楼

完了，是個女聖祖。
估計又要曖昧一下了。肯定是沒有要動手。

i*h2015-04-01 07:04

7 楼

d*n2015-04-01 07:04

8 楼

http over ssl is a must

t*n2015-04-01 07:04

9 楼

交学费吧，花钱拿回来不值

about

【在 h*****e 的大作中提到】

r*o2015-04-01 07:04

10 楼

男的打脸，女的暧昧，这是一定的

【在 c****i 的大作中提到】

: 完了，是個女聖祖。
: 估計又要曖昧一下了。肯定是沒有要動手。

g*d2015-04-01 07:04

11 楼

dell的有时要到dell wireless utility里面去search.

s*y2015-04-01 07:04

12 楼

有vpn也需要ssl吗？

【在 d****n 的大作中提到】

: http over ssl is a must

c*g2015-04-01 07:04

13 楼

惜，没后悔药卖。省了1，2刀，丢了45k miles。

T*s2015-04-01 07:04

14 楼

弄出个宝花的亲姐
宝花也该养好伤了吧

d*n2015-04-01 07:04

15 楼

intranet 就不堤防同事了？
http tcp packet被拦截了肿么办？都是赤果果的text

【在 s****y 的大作中提到】

:
: 有vpn也需要ssl吗？

h*e2015-04-01 07:04

16 楼

What doe is mean "省了1，2刀"? What do you guys do to spend a couple of
dollars to keep the miles?
It may help in the future. Thank you.

【在 c****g 的大作中提到】

: 惜，没后悔药卖。省了1，2刀，丢了45k miles。

a*m2015-04-01 07:04

17 楼

莲花圣祖姐妹，疗伤圣药是莲花。这后面一定有个大阴谋。元芳，你怎么看？

【在 T*********s 的大作中提到】

: 弄出个宝花的亲姐
: 宝花也该养好伤了吧

w*z2015-04-01 07:04

18 楼

it depends , if it is sensitive data, use https

【在 s****y 的大作中提到】

:
: 有vpn也需要ssl吗？

D*E2015-04-01 07:04

19 楼

TRAVEL版置顶FAQ

【在 h*****e 的大作中提到】

: What doe is mean "省了1，2刀"? What do you guys do to spend a couple of
: dollars to keep the miles?
: It may help in the future. Thank you.

c*r2015-04-01 07:04

20 楼

估计几百亿里面才能出一个圣祖，结果宝花一家生出两圣祖，这得多光宗耀祖啊。

n*42015-04-01 07:04

21 楼

用Spring Security + OAuth 2.0。这里有样本code：
http://porterhead.blogspot.com/2014/05/securing-rest-services-w
有钱的上Apigee或SiteMinder Web Service Package.

【在 s****y 的大作中提到】

: 在企业级应用中，iOS和Java之间用RESTful通信，如果想提高安全性，用什么比较好？
: OAuth是不是一种选择？还有其他的吗？

k*82015-04-01 07:04

22 楼

1万5千迈，大概要花200多才能找回来。
我也过期了，刚来的时候压根不知道mileage有啥用

n*d2015-04-01 07:04

23 楼

不稀奇，参考清华学霸姐妹

【在 c*********r 的大作中提到】

: 估计几百亿里面才能出一个圣祖，结果宝花一家生出两圣祖，这得多光宗耀祖啊。

g*g2015-04-01 07:04

24 楼

OAuth can cover authentication only, you still need to have authorization
using frameworks like spring security.

【在 s****y 的大作中提到】

: 在企业级应用中，iOS和Java之间用RESTful通信，如果想提高安全性，用什么比较好？
: OAuth是不是一种选择？还有其他的吗？

n*l2015-04-01 07:04

25 楼

大人，这里一定有蹊跷。。。

【在 a******m 的大作中提到】

: 莲花圣祖姐妹，疗伤圣药是莲花。这后面一定有个大阴谋。元芳，你怎么看？

c*e2015-04-01 07:04

26 楼

大牛给比较一下basic authentication和OAuth ？

【在 g*****g 的大作中提到】

: OAuth can cover authentication only, you still need to have authorization
: using frameworks like spring security.

e*d2015-04-01 07:04

27 楼

最近怎么和之前忘语的风格不一样了，
情节推进很快，行云流水，没有废话和表情表示老魔的心里活动
这是代笔么，还是想马上结束了？？？

g*g2015-04-01 07:04

28 楼

一个是SSO，一个是本地罢了。

【在 c*********e 的大作中提到】

: 大牛给比较一下basic authentication和OAuth ？

t*e2015-04-01 07:04

29 楼

还是有的，比如“银月和蟹道人自然没有反对的意思”

【在 e*******d 的大作中提到】

: 最近怎么和之前忘语的风格不一样了，
: 情节推进很快，行云流水，没有废话和表情表示老魔的心里活动
: 这是代笔么，还是想马上结束了？？？

c*e2015-04-01 07:04

30 楼

但是，真正用oauth来登录的人多吗？即使是用gmail,facebook什么的用户名和密码来
登录，那hacker能知道gmail,facebook的用户名和密码，以后一样能用它来登录啊,而
且还能把你的google contacts,google drive data给全部拿到,在你的facebook上乱发
文。hacker要的是能登录你的帐号就行，不管是用什么方法。何况，现在password在
hacker眼里根本就是渣。
---------------
一个是SSO，一个是本地罢了。

【在 c*********e 的大作中提到】

: 大牛给比较一下basic authentication和OAuth ？

s*y2015-04-01 07:04

31 楼

请问你说的这些有没有什么好的资料和书可以推荐？

ET2015-04-01 07:04

32 楼

https is a must.
oauth is a way to authenticate a user from a third-party service without
sharing this user's login credential.
Security is a big topic. It depends on your use case. Authenticating a user,
username + password with http basic authentication is common used. Some
service provider uses plain text of user's password over https, it is also
OK. It's better to hash the user's password, then keep hashed password on
server.
It's better to block the password attempting numbers or it will end up like
Sony network's case.
it's very popular nowadays, RESTful service uses API key and secret as the
way to make requests. API key and secret are plain text on mobile apps if
reversing engineering is done right. It means anyone who has this api key
and secret, they can make API request, and do the CRUD if no measure is
taken to protect those.
Overall, it has to make sure who can read data only, and who can write, edit
and delete.

【在 s****y 的大作中提到】

: 在企业级应用中，iOS和Java之间用RESTful通信，如果想提高安全性，用什么比较好？
: OAuth是不是一种选择？还有其他的吗？

g*g2015-04-01 07:04

33 楼

Authentication and authorization are two different things. It's like the
entry to club and VIP room has different requirements.
With authentication you identify the user and pull the user's
roles in session, you use the roles for authorization on every request.
Since the user context is in server side session, hacker cannot modify it.

user,
like

【在 ET 的大作中提到】

: https is a must.
: oauth is a way to authenticate a user from a third-party service without
: sharing this user's login credential.
: Security is a big topic. It depends on your use case. Authenticating a user,
: username + password with http basic authentication is common used. Some
: service provider uses plain text of user's password over https, it is also
: OK. It's better to hash the user's password, then keep hashed password on
: server.
: It's better to block the password attempting numbers or it will end up like
: Sony network's case.

l*n2015-04-01 07:04

34 楼

use node passport.

【在 s****y 的大作中提到】

: 在企业级应用中，iOS和Java之间用RESTful通信，如果想提高安全性，用什么比较好？
: OAuth是不是一种选择？还有其他的吗？

ET2015-04-01 07:04

35 楼

what you are saying is a standard web app. For most mobile apps I know (not
those bank apps), there is no session used on mobile app. Have you ever seen
your gmail iPhone app session you out?
most of mobile app, you login with you credential, get a token which might
come with an expiration date, but it is barely used. If it is used, you need
to re-enter your login credential. But look at your facebook app,
instagram, twitter, when do you need to enter your login credential again?
Amazon mobile app needs, some other ecommerce apps need as well. Some just
don't.
The second thing about the token you obtain, can actually share among
different devices and/or web apps. It's a security hole. Believe or not,
many companies apps do have this security hole.
role based authorization is better, I have said so. it's not every app
having that.

【在 g*****g 的大作中提到】

: Authentication and authorization are two different things. It's like the
: entry to club and VIP room has different requirements.
: With authentication you identify the user and pull the user's
: roles in session, you use the roles for authorization on every request.
: Since the user context is in server side session, hacker cannot modify it.
:
: user,
: like

g*g2015-04-01 07:04

36 楼

Mobile app typically saves password locally with mask. It's a
personal device and there's nothing wrong with that approach. Browser allows
you to do it too. Session is still generated on server side with logined
user profile, otherwise one can easily change other's data. i.e. You
authenticate with a cookie. It's true that cookie can be used by other
device while valid, but the session cookie is typically short lifed. And on
https, it's not easily stolen.

not
seen
need

【在 ET 的大作中提到】

: what you are saying is a standard web app. For most mobile apps I know (not
: those bank apps), there is no session used on mobile app. Have you ever seen
: your gmail iPhone app session you out?
: most of mobile app, you login with you credential, get a token which might
: come with an expiration date, but it is barely used. If it is used, you need
: to re-enter your login credential. But look at your facebook app,
: instagram, twitter, when do you need to enter your login credential again?
: Amazon mobile app needs, some other ecommerce apps need as well. Some just
: don't.
: The second thing about the token you obtain, can actually share among

ET2015-04-01 07:04

37 楼

come on. no good app saves user's password or its modification. Your
webservice has already provided session with token info. all we save is the
token.
look at your browser's cookie, you find a token. When you make an api
request, you exchange the token, not user's credential.

allows
on

【在 g*****g 的大作中提到】

: Mobile app typically saves password locally with mask. It's a
: personal device and there's nothing wrong with that approach. Browser allows
: you to do it too. Session is still generated on server side with logined
: user profile, otherwise one can easily change other's data. i.e. You
: authenticate with a cookie. It's true that cookie can be used by other
: device while valid, but the session cookie is typically short lifed. And on
: https, it's not easily stolen.
:
: not
: seen

d*n2015-04-01 07:04

38 楼

+1. I would not design an app save any form of user's password at client
side.
The difference is you might lost your token but you wont lost your password.

the

【在 ET 的大作中提到】

: come on. no good app saves user's password or its modification. Your
: webservice has already provided session with token info. all we save is the
: token.
: look at your browser's cookie, you find a token. When you make an api
: request, you exchange the token, not user's credential.
:
: allows
: on

g*g2015-04-01 07:04

39 楼

A remember me token that doesn't expire is worse than saving password masked
IMHO.
Mitbbs app saves your password, so does every browser on desktop. And while
you can go sessionless on restful, it may hurt performance if you expect
many interactions after first. There are all choice, not rule.

the

【在 ET 的大作中提到】

g*g2015-04-01 07:04

40 楼

All browser vendors don't agree. As long as you provide choice, it's up to
user to decide if they want to save password locally.

password.

【在 d****n 的大作中提到】

: +1. I would not design an app save any form of user's password at client
: side.
: The difference is you might lost your token but you wont lost your password.
:
: the

d*n2015-04-01 07:04

41 楼

Browser vendor 是它的事情，我的app是我的事情。
要是密码从我这http request/response泄露了，user不得骂死我。
要vendor save password那是user自愿的事情。
没人反对你在哪保存user密码。
道高一尺魔高一丈，安全与反安全都是相对的。时代在发展，安全策略也是。

【在 g*****g 的大作中提到】

: All browser vendors don't agree. As long as you provide choice, it's up to
: user to decide if they want to save password locally.
:
: password.

g*g2015-04-01 07:04

42 楼

https 下自然是不会从 R/R里丢的。像你那样存个不过期的 token丢了都不知道。密码
也可以本地 hash的。如果你担心的是被监听，一个不过期的token要比发一次
password登录接下来是一个会过期的token更危险。

【在 d****n 的大作中提到】

: Browser vendor 是它的事情，我的app是我的事情。
: 要是密码从我这http request/response泄露了，user不得骂死我。
: 要vendor save password那是user自愿的事情。
: 没人反对你在哪保存user密码。
: 道高一尺魔高一丈，安全与反安全都是相对的。时代在发展，安全策略也是。

d*n2015-04-01 07:04

43 楼

https is a must!早就说过了。你不要混淆安全范畴。
就说密码的事，不是https,也不是browser.
假设ｔｏｋｅｎ丢了，被别人伪造，
情景一，在别的电脑上伪造，会自然被ｄｅｎｙ。最差的情况是小偷一直用这个ｔｏｋ
ｅｎ,但是每办法知道你的密码，一般改设密码要再次输入明文，而不是ｌｏｇｉｎ就
可以。
你应该知道一个企业用户的明文密码比一个ｔｏｋｅｎ要重要多了吧？
有时候你ｌｄａｐ认证，没法改变密码，丢了你的ｓｔｏｃｋ，４０１ｋ就逗逼了。
一个ｔｏｋｅｎ丢了就丢了吧。
情景二，在同一电脑上伪造，基本无药可救。你走了，别人坐你电脑上，神仙也帮不了
你。

d*n2015-04-01 07:04

44 楼

ｈｔｔｐｓ也不一定安全多少，google chrome　CA的也不一定比ｓｅｌｆ－ｓｉｇｎ的
安全多少。
都一个吊味。不同的就是你的证书在ｃａ　ｃｏｍｐａｎｙ被黑，还是自己的　ｃｏｍ
ｐｕｔｅｒ被盗用。
不要问我怎么伪造ｃａ，我没那本事，但是不代表别人也没有。
FYI: http://techcrunch.com/2015/04/01/google-cnnic/

【在 g*****g 的大作中提到】

: https 下自然是不会从 R/R里丢的。像你那样存个不过期的 token丢了都不知道。密码
: 也可以本地 hash的。如果你担心的是被监听，一个不过期的token要比发一次
: password登录接下来是一个会过期的token更危险。

g*g2015-04-01 07:04

45 楼

Google 根本不是顶级 CA，他能发的 key连你的网站都匹配不了，别扯淡了。

【在 d****n 的大作中提到】

: ｈｔｔｐｓ也不一定安全多少，google chrome　CA的也不一定比ｓｅｌｆ－ｓｉｇｎ的
: 安全多少。
: 都一个吊味。不同的就是你的证书在ｃａ　ｃｏｍｐａｎｙ被黑，还是自己的　ｃｏｍ
: ｐｕｔｅｒ被盗用。
: 不要问我怎么伪造ｃａ，我没那本事，但是不代表别人也没有。
: FYI: http://techcrunch.com/2015/04/01/google-cnnic/

d*n2015-04-01 07:04

46 楼

说密码的事

【在 g*****g 的大作中提到】

: Google 根本不是顶级 CA，他能发的 key连你的网站都匹配不了，别扯淡了。

g*g2015-04-01 07:04

47 楼

就是你觉得而已。重要的是数据，不是密码，一个用不过期的 token是最危险的。发密
码好歹只有一次。还有很多网站是登录要 https, 访问不用的，打死我都不会用不过期
的 token.

【在 d****n 的大作中提到】

: https is a must!早就说过了。你不要混淆安全范畴。
: 就说密码的事，不是https,也不是browser.
: 假设ｔｏｋｅｎ丢了，被别人伪造，
: 情景一，在别的电脑上伪造，会自然被ｄｅｎｙ。最差的情况是小偷一直用这个ｔｏｋ
: ｅｎ,但是每办法知道你的密码，一般改设密码要再次输入明文，而不是ｌｏｇｉｎ就
: 可以。
: 你应该知道一个企业用户的明文密码比一个ｔｏｋｅｎ要重要多了吧？
: 有时候你ｌｄａｐ认证，没法改变密码，丢了你的ｓｔｏｃｋ，４０１ｋ就逗逼了。
: 一个ｔｏｋｅｎ丢了就丢了吧。
: 情景二，在同一电脑上伪造，基本无药可救。你走了，别人坐你电脑上，神仙也帮不了

d*n2015-04-01 07:04

48 楼

你还是在原地打转，你自己愿意丢个密码还是ｔｏｋｅｎ?
密码是数据的开门钥匙，密码都没了，要数据干啥？还不赶紧换密码，挪数据？
ｔｏｋｅｎ有其他的ｗｒａｐ　ａｒｏｕｎｄ，譬如定期服务器ｅｘｐｉｒａｔｉｏｎ.
要是用户发现被黑了，换个密码。多大个事。
我和你的讨论到此为止，你爱存ｈａｓｈｅｄ　ｐａｓｓｗｏｒｄ在客户端是你的个人
偏好。我没意见。
btw:sha-1被ｇｏｏｇｌｅ弃用了，啥时候ｓｈａ－２５６可能就是等硬件更新的时候。
https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1

【在 g*****g 的大作中提到】

: 就是你觉得而已。重要的是数据，不是密码，一个用不过期的 token是最危险的。发密
: 码好歹只有一次。还有很多网站是登录要 https, 访问不用的，打死我都不会用不过期
: 的 token.

g*g2015-04-01 07:04

49 楼

一个不过期的token，爱干啥干啥，还要密码干什么。密码好歹一个 session只用一次
。你的 token可是每个request都用，被搞的概率大多了。

ｎ.
候。

【在 d****n 的大作中提到】

: 你还是在原地打转，你自己愿意丢个密码还是ｔｏｋｅｎ?
: 密码是数据的开门钥匙，密码都没了，要数据干啥？还不赶紧换密码，挪数据？
: ｔｏｋｅｎ有其他的ｗｒａｐ　ａｒｏｕｎｄ，譬如定期服务器ｅｘｐｉｒａｔｉｏｎ.
: 要是用户发现被黑了，换个密码。多大个事。
: 我和你的讨论到此为止，你爱存ｈａｓｈｅｄ　ｐａｓｓｗｏｒｄ在客户端是你的个人
: 偏好。我没意见。
: btw:sha-1被ｇｏｏｇｌｅ弃用了，啥时候ｓｈａ－２５６可能就是等硬件更新的时候。
: https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1

d*n2015-04-01 07:04

50 楼

我同意你的观点，可是至今没有更完美的solution. complexity v.s. security
还有，session和你的client side password hash 又不是一个讨论范畴。
session占资源，delay是众所周知的。但是ｓｅｓｓｉｏｎ也不是攻不可破的。
好的安全系统是ａｐｐ主机都被黑了，ａｐｐ数据库都开放了，可是小偷就是没办法拿
到明文密码。

【在 g*****g 的大作中提到】

: 一个不过期的token，爱干啥干啥，还要密码干什么。密码好歹一个 session只用一次
: 。你的 token可是每个request都用，被搞的概率大多了。
:
: ｎ.
: 候。

ET2015-04-01 07:04

51 楼

for last comment, that's true. people make software services in all ways.
what set good and bad apart is obvious.

masked
while

【在 g*****g 的大作中提到】

: A remember me token that doesn't expire is worse than saving password masked
: IMHO.
: Mitbbs app saves your password, so does every browser on desktop. And while
: you can go sessionless on restful, it may hurt performance if you expect
: many interactions after first. There are all choice, not rule.
:
: the

g*g2015-04-01 07:04

52 楼

Restful service is typically stateless but not sessionless, unless it's not
exposed to edge and it doesn't need authentication/authorization. In the
latter case, it's OK to only secure the edge service. Session can also be
moved to Memcache/Redis/C*.

【在 ET 的大作中提到】

: for last comment, that's true. people make software services in all ways.
: what set good and bad apart is obvious.
:
: masked
: while

ET2015-04-01 07:04

53 楼

then you should delete most apps on your iPhone.

【在 g*****g 的大作中提到】

g*g2015-04-01 07:04

54 楼

I don't have an iphone. And the truth is encrypting password with keychain
is much safer than having a permanent remember-me token in clear text. I am
an expert on PKI and I know this better than average Joe.

【在 ET 的大作中提到】

: then you should delete most apps on your iPhone.

ET2015-04-01 07:04

55 楼

With all due respect for your knowledge in security and for the purpose of
clarification, saving a user's password is a bad practice. OK. Why do you
want to do that? You like put something into keychain, you can do the token
for enhancing the security. And, not all the web services have been designed
to handle username/password to make API requests. They just use token. What
do you use password for?
I am not gonna bring to another level discussion about jailbroken devices
and rooted devices. Tell me you trust the keychain services in the
jailbroken iOS devices and rooted android devices.
This discussion is for the knowledge sharing purpose.

am

【在 g*****g 的大作中提到】

: I don't have an iphone. And the truth is encrypting password with keychain
: is much safer than having a permanent remember-me token in clear text. I am
: an expert on PKI and I know this better than average Joe.

g*g2015-04-01 07:04

56 楼

For a service provider, losing an access token is no different from losing
the password. Only worse it's in clear text. There's no holy grail, but I
fail to see how your proposal is better.

token
designed
What

【在 ET 的大作中提到】

: With all due respect for your knowledge in security and for the purpose of
: clarification, saving a user's password is a bad practice. OK. Why do you
: want to do that? You like put something into keychain, you can do the token
: for enhancing the security. And, not all the web services have been designed
: to handle username/password to make API requests. They just use token. What
: do you use password for?
: I am not gonna bring to another level discussion about jailbroken devices
: and rooted devices. Tell me you trust the keychain services in the
: jailbroken iOS devices and rooted android devices.
: This discussion is for the knowledge sharing purpose.