XSF Discussion - 2020-05-11


  1. govanify has left
  2. govanify has joined
  3. pdurbin has left
  4. chyna has joined
  5. mukt2 has left
  6. moparisthebest has joined
  7. Neustradamus_ has left
  8. Neustradamus has left
  9. govanify has left
  10. govanify has joined
  11. govanify has left
  12. govanify has joined
  13. emus has left
  14. stpeter has joined
  15. calvin has left
  16. sonny has left
  17. sonny has joined
  18. sonny has left
  19. sonny has joined
  20. moparisthebest has left
  21. govanify has left
  22. govanify has joined
  23. govanify has left
  24. govanify has joined
  25. stpeter has left
  26. govanify has left
  27. govanify has joined
  28. govanify has left
  29. govanify has joined
  30. arc has left
  31. arc has joined
  32. govanify has left
  33. govanify has joined
  34. govanify has left
  35. govanify has joined
  36. govanify has left
  37. govanify has joined
  38. govanify has left
  39. govanify has joined
  40. paul has left
  41. Neustradamus_ has joined
  42. Neustradamus_ has left
  43. Neustradamus_ has joined
  44. govanify has left
  45. govanify has joined
  46. karoshi has left
  47. Neustradamus_ has left
  48. Neustradamus_ has joined
  49. arc has left
  50. arc has joined
  51. sonny has left
  52. sonny has joined
  53. Maranda has left
  54. pdurbin has joined
  55. Maranda has joined
  56. govanify has left
  57. govanify has joined
  58. pdurbin has left
  59. sonny has left
  60. sonny has joined
  61. govanify has left
  62. govanify has joined
  63. dr.json has joined
  64. APach has left
  65. APach has joined
  66. xsf has left
  67. xsf has joined
  68. sonny has left
  69. sonny has joined
  70. dr.json has left
  71. dr.json has joined
  72. govanify has left
  73. govanify has joined
  74. pdurbin has joined
  75. calvin has joined
  76. dr.json has left
  77. stpeter has joined
  78. govanify has left
  79. govanify has joined
  80. bear has left
  81. govanify has left
  82. govanify has joined
  83. arc has left
  84. arc has joined
  85. Zash has left
  86. calvin has left
  87. calvin has joined
  88. calvin has left
  89. calvin has joined
  90. arc has left
  91. arc has joined
  92. stpeter has left
  93. Zash has joined
  94. dr.json has joined
  95. Neustradamus_ has left
  96. sonny has left
  97. sonny has joined
  98. Neustradamus_ has joined
  99. calvin has left
  100. sonny has left
  101. sonny has joined
  102. dr.json has left
  103. arc has left
  104. arc has joined
  105. arc has left
  106. arc has joined
  107. j.r has left
  108. arc has left
  109. arc has joined
  110. arc has left
  111. arc has joined
  112. arc has left
  113. arc has joined
  114. arc has left
  115. arc has joined
  116. gav has left
  117. j.r has joined
  118. waqas has left
  119. bear has joined
  120. andy has joined
  121. govanify has left
  122. govanify has joined
  123. govanify has left
  124. govanify has joined
  125. govanify has left
  126. govanify has joined
  127. Seve has joined
  128. xsf has left
  129. xsf has joined
  130. arc has left
  131. arc has joined
  132. xsf has left
  133. xsf has joined
  134. andrey.g has joined
  135. DebXWoody has joined
  136. Yagiza has joined
  137. xsf has left
  138. xsf has joined
  139. j.r has left
  140. xsf has left
  141. xsf has joined
  142. govanify has left
  143. govanify has joined
  144. mimi89999 has left
  145. mimi89999 has joined
  146. xsf has left
  147. xsf has joined
  148. j.r has joined
  149. DebXWoody has left
  150. lovetox has joined
  151. mukt2 has joined
  152. Tobias has joined
  153. stpeter has joined
  154. larma has left
  155. lovetox has left
  156. Mikaela has joined
  157. larma has joined
  158. lovetox has joined
  159. lorddavidiii has joined
  160. arc has left
  161. arc has joined
  162. paul has joined
  163. arc has left
  164. arc has joined
  165. stpeter has left
  166. Jeybe has joined
  167. gav has joined
  168. j.r has left
  169. sonny has left
  170. sonny has joined
  171. sonny has left
  172. sonny has joined
  173. LNJ has joined
  174. bear has left
  175. mukt2 has left
  176. j.r has joined
  177. govanify has left
  178. govanify has joined
  179. LNJ has left
  180. LNJ has joined
  181. mukt2 has joined
  182. chyna has left
  183. bear has joined
  184. arc has left
  185. arc has joined
  186. chyna has joined
  187. LNJ has left
  188. lovetox has left
  189. mukt2 has left
  190. arc has left
  191. arc has joined
  192. emus has joined
  193. jonas’ has left
  194. jonas’ has joined
  195. jonas’ has left
  196. jonas’ has joined
  197. Maranda Metronome if the internal hashed auth backend is used just stores sha-1/256/384/512 server keys hash variants in the account credentials datastore whenever a password is generated
  198. DebXWoody has joined
  199. stpeter has joined
  200. mukt2 has joined
  201. arc has left
  202. arc has joined
  203. Maranda So it's more if you see DIGEST-MD5 offered to be a symptom that passwords are stored in plain
  204. sonny has left
  205. sonny has joined
  206. krauq has left
  207. krauq has joined
  208. arc has left
  209. arc has joined
  210. arc has left
  211. arc has joined
  212. stpeter has left
  213. arc has left
  214. arc has joined
  215. arc has left
  216. arc has joined
  217. lovetox has joined
  218. adiaholic_ has left
  219. adiaholic_ has joined
  220. goffi has joined
  221. xecks has joined
  222. mukt2 has left
  223. adiaholic_ has left
  224. adiaholic_ has joined
  225. Jeybe has left
  226. Jeybe has joined
  227. Jeybe has left
  228. Jeybe has joined
  229. sonny has left
  230. sonny has joined
  231. sonny has left
  232. sonny has joined
  233. mukt2 has joined
  234. Daniel has left
  235. Daniel has joined
  236. mukt2 has left
  237. nyco has left
  238. mukt2 has joined
  239. dwd has joined
  240. debacle has joined
  241. dwd Just reading back, I'm not actually sure of the reason I made SASL2 use a distinct stream feature. But as I've previously said, anything that makes SASL2 have a namespace bump to urn:xmpp:sasl:2 is fine by me. :-)
  242. dwd Also: https://tools.ietf.org/html/rfc5802#section-6.1 does indeed say that servers MUST tls-unique, and that clients SHOULD. But all normative requirements can be altered by negotiation, meaning that clients implicitly MAY use anything that the server explicitly says it can support.
  243. debacle has left
  244. sonny has left
  245. sonny has joined
  246. sonny has left
  247. sonny has joined
  248. Neustradamus_ Thanks people to look SCRAM-SHA-256 and TLS Binding for -PLUS SCRAM variants.
  249. dwd larma, Final note - we're stuck with -PLUS because that comes from the SASL layer (or quite possibly the GS2 layer).
  250. nyco has joined
  251. dwd Maranda, DIGEST-MD% doesn't need to store a plaintext password, though it does essentially mandate a plaintext equivalent. CRAM-MD5 has to store plaintext passwords, though, unless you do really shady things with partially computed HMACs.
  252. mukt2 has left
  253. lovetox has left
  254. Neustradamus_ If you search more informations: Do not lost this link: https://github.com/scram-xmpp/info/issues/1
  255. rion has left
  256. karoshi has joined
  257. rion has joined
  258. larma dwd: I don't read the SCRAM RFC as if there was no way to work without -PLUS.
  259. paul has left
  260. mukt2 has joined
  261. Dele Olajide has joined
  262. Neustradamus_ Do not forget the RFC 8600: https://tools.ietf.org/html/rfc8600 which it was published 2019-06-21 (soon one year): "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
  263. Neustradamus_ Do not forget the RFC 8600: https://tools.ietf.org/html/rfc8600 which has been published 2019-06-21 (soon one year): "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
  264. krauq has left
  265. Guus Is there someone in here with administrative powers on tigase.org ?
  266. Neustradamus_ Guus: tigase@muc.tigase.org
  267. Guus Given that I want to discuss connectivity issues, that's not ideal. 🙂
  268. Neustradamus_ I have informed you some days ago ;)
  269. Neustradamus_ I have invited people here
  270. Dele Olajide has left
  271. Guus Thanks
  272. Dele Olajide has joined
  273. larma Neustradamus_: RFC 8600 is not relevant for most XMPP software (especially anything chat related). It merely "defines how to use XMPP for the exchange of security notifications on a controlled-access network among authorized entities"
  274. stpeter has joined
  275. Neustradamus_ Maybe but SCRAM part is important.
  276. Neustradamus_ And it is logic.
  277. debacle has joined
  278. Andrzej has joined
  279. adiaholic_ has left
  280. adiaholic_ has joined
  281. dwd But it's largely a profile of XMPP for a specific purpose - specifically, it doesn't update RFC 6120.
  282. Neustradamus_ Guus: Andrzej from Tigase here
  283. dwd And if it had tried to, I would have shot that one down.
  284. sonny has left
  285. sonny has joined
  286. sonny has left
  287. sonny has joined
  288. larma It also says servers MUST support at least SCRAM or EXTERNAL. Which obviously should not apply to all XMPP usecases.
  289. krauq has joined
  290. Dele Olajide has left
  291. Dele Olajide has joined
  292. mukt2 has left
  293. emus has left
  294. stpeter has left
  295. mukt2 has joined
  296. emus has joined
  297. debacle has left
  298. Neustradamus_ larma: XMPP server softwares do it: - Prosody IM: https://modules.prosody.im/mod_auth_external.html - Metronome IM: https://github.com/maranda/metronome/blob/master/plugins/mod_auth_external.lua - ejabberd: https://github.com/processone/ejabberd/blob/master/src/ejabberd_auth_external.erl - Mongoose IM: https://github.com/esl/MongooseIM/tree/master/src/auth
  299. larma Neustradamus_: that doesn't make RFC8600 relevant in this context
  300. reedhhw has joined
  301. sonny has left
  302. sonny has joined
  303. sonny has left
  304. sonny has joined
  305. reedhhw has left
  306. larma Nobody is saying implementing SCRAM-SHA-256/-512 is a bad idea. But that doesn't mean it necessarily has the priority you are suggesting everywhere.
  307. reedhhw has joined
  308. larma I bet that if you do a pull request to any software that doesn't implement it yet, it would be accepted. But you can't blame developers for not giving it the priority you'd like.
  309. Steve Kille has left
  310. Neustradamus_ larma: the point is have the good order from best to worst SCRAM and RFC 8600 (stpeter is an author): "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
  311. Neustradamus_ It is not SCRAM-SHA-256 = SCRAM-SHA-1 or SCRAM-SHA-1 is preferred to SCRAM-SHA-256...
  312. Neustradamus_ We can understand: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1
  313. Steve Kille has joined
  314. Neustradamus_ It is like DIGEST-MD5 > CRAM-MD5
  315. Neustradamus_ Of course if the XMPP server supports, we can see in XMPP clients: - if only SCRAM-SHA-1 it is easy - if only SCRAM-SHA-256 it is easy - if SCRAM-SHA-1-PLUS and SCRAM-SHA-1 // SCRAM-SHA-1-PLUS > SCRAM-SHA-1 - if SCRAM-SHA-256 and SCRAM-SHA-1 // SCRAM-SHA-256 > SCRAM-SHA-1 - if SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1 - if SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS // SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS
  316. Neustradamus_ Of course if the XMPP server supports, we can see in XMPP clients: - if only SCRAM-SHA-1 it is easy - if SCRAM-SHA-1-PLUS and SCRAM-SHA-1 // SCRAM-SHA-1-PLUS > SCRAM-SHA-1 - if only SCRAM-SHA-256 it is easy - if SCRAM-SHA-256-PLUS and SCRAM-SHA-256 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 - if SCRAM-SHA-256 and SCRAM-SHA-1 // SCRAM-SHA-256 > SCRAM-SHA-1 - if SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1 - if SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS // SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS
  317. Maranda dwd: I didn't say it does, I said that "in Metronome it does"
  318. dwd Maranda, Ah, gotcha.
  319. debacle has joined
  320. Maranda The only auth backend that does provide DIGEST-MD5 is the internal plain one
  321. paul has joined
  322. adiaholic_ has left
  323. adiaholic_ has joined
  324. lovetox has joined
  325. xsf has left
  326. Neustradamus_ has left
  327. Neustradamus_ has joined
  328. lskdjf has joined
  329. larma Neustradamus_, I think it's clear to everyone that IF both server and client support both SHA-1 and SHA-256, SHA-256 should be preferred. And that IF both server and client support -PLUS, -PLUS should be preferred. You apparently left out the small sidecase where SCRAM-SHA-1-PLUS and SCRAM-SHA-256 are supported, because it's not obvious what is to be preferred then (IMO it's -PLUS).
  330. jonas’ (agreed on -PLUS over SHA2)
  331. larma However the default today is a) servers typically don't offer SHA-256 because the password is hashed with SHA-1 in database, making it impossible to offer SHA-256. There is no proper upgrade path from SHA-1 to SHA-256. b) clients don't offer SHA-256 because servers typically don't and it's not worth the effort to implement it for the very few cases where servers do. Because basically in all cases one can just fallback to PLAIN anyway without significant loss in security (if users follow best practices for passwords)
  332. jonas’ in my arrogant developer opinion, if implementing SHA-256 is hard after you have the SHA-1 variant implemented, you are in dire need of refactoring.
  333. larma jonas’, that is indeed true 😉
  334. larma but it needs to be tested, which is already hard enough given there are so few servers in practice supporting it 😉
  335. jonas’ I’m a believer in test-driven development, and if my SHA-1 implementation passes the test vectors, I’m confident enough that the SHA-256 variant will work flawlessly.
  336. larma IMO there is also a design fail in how we login that I have to present the mechanisms *before* knowing the login name.
  337. larma Was that tackled by sasl2?
  338. jonas’ larma, presenting the mechanisms afterwards would be a security problem
  339. jonas’ you could test user existence then
  340. larma as if that wasn't possible already through various ways...
  341. larma also servers could answer with fake mechanisms if user doesn't exist...
  342. sonny has left
  343. sonny has joined
  344. jonas’ larma, the fake mechanisms would still look different than some user’s real mechanisms
  345. sonny has left
  346. sonny has joined
  347. jonas’ and AFAIK user enumeration is a problem we generally avoid *by default* if possible.
  348. larma server could send the mechanisms that are send to the largest amount of users on the server. Than it's still possible to detect some users, but not all.
  349. jonas’ yeah, and expensive to figure that out.
  350. larma However the advantage is huge as that would allow an upgrade path for the hash algorithm
  351. jonas’ could do that with SASL2 already, though it requires offering *only* the old mechanism until all accounts have been upgraded.
  352. larma even in that case you have to store both password hashes for the time until all accounts upgraded. If it was per user, you could just do it per user. You could even decide server-side based on the clients that connected previously if you want to upgrade a user or not.
  353. jonas’ yes, but that’s not feasible unless you want to allow user enumeration.
  354. jonas’ yes, but that’s not feasible unless you want to allow user probing.
  355. jonas’ which RFC 6120 and RFC 6121 go a long way to avoid.
  356. jonas’ nevermind that vcard-temp and possibly other things allow it if the user explicitly published some data
  357. larma IMO, user enumeration is when I can get a list of users, not when I can try out every possible JID.
  358. jonas’ but the default is that you can’t enumerate accounts.
  359. jonas’ larma, that’s why I /correct’d my message.
  360. larma right.
  361. jonas’ s/enumerate/probe/
  362. larma well there are a ton of XEPs where you can probe users
  363. jonas’ but only after the users did sometihng to allow that
  364. larma not even sure if it's not possible by RFC, but certainly by CS2020
  365. larma PEP for example makes users probe-able
  366. jonas’ I’m aware of that
  367. jonas’ but it shouldn’t be the default.
  368. jonas’ (and it isn’t)
  369. larma that you have PEP?
  370. jonas’ that you have a PEP node which is world-readable
  371. larma you don't need that
  372. jonas’ you don’t?
  373. larma even if it's not readable, you get different errors
  374. jonas’ that’s a bug then
  375. jonas’ either in the standard or in the implementations
  376. larma also pubsub nodes MUST be disco-able
  377. jonas’ I’m fairly certain that you can always return <forbidden/> if you don’t want to let someone read nodes
  378. larma jonas’, you could but it wouldn't be XEP-compliant. Also that doesn't solve the pubsub must be disco-able. If it wasn't you couldn't have world-readable PEP nodes.
  379. jonas’ larma, then the XEP needs to be fixed
  380. jonas’ but I’m sitll fairly certain that you can do that without having to fix the XEP
  381. jonas’ ah, maybe only returning the items you can actually see would suffice already
  382. karoshi has left
  383. jonas’ my point is: those are issues which can and need to be fixed
  384. karoshi has joined
  385. jonas’ that they exist is no reason to open more issues.
  386. larma but if a user doesn't exist it also doesn't have a pep service on it's jid
  387. jonas’ larma, servers could easily pretend that
  388. jonas’ larma, servers could easily pretend that there is an empty pep service.
  389. larma I think it's just plain ignorant to claim that users are not probe-able and thus we should design protocols such that this remains true.
  390. jonas’ that’s a valid opinion. I disagree.
  391. Nekit has left
  392. Nekit has joined
  393. larma Do you think it's likely we'll ever reach the state where user probing is not possible?
  394. jonas’ yes
  395. pdurbin has left
  396. nyco has left
  397. nyco has joined
  398. larma ok, so how would you like to do the upgrade then?
  399. jonas’ as I wrote above
  400. jonas’ you’ll have to wait for all accounts to be upgraded
  401. jonas’ typically that’s done with a deadline after which users have to use a password reset facility to regain access
  402. jonas’ or their account is deleted
  403. Neustradamus_ It is possible to have SCRAM-SHA-256(-PLUS) and SCRAM-SHA-1(-PLUS) enabled on an XMPP server but some users with only SCRAM-SHA-1 passwords (if originally not in PLAIN). If the user change of password, SCRAM-SHA-1 and SCRAM-SHA-256 will be here.
  404. Holger Users love changing passwords for random reasons.
  405. larma Neustradamus_, upgrade only makes sense when we don't support SHA-1 afterwards (or at least that's when it really makes a difference)
  406. Neustradamus_ Currently: Jackal XMPP server, Metronome IM, Mongoose IM master (soon a release), Prosody 0.12-dev, Tigase are already good.
  407. Holger We should just switch *TODAY*.
  408. Zash Flag day?
  409. Holger (kk I'll get coffee and quite trolling.)
  410. Holger quit
  411. Daniel This will instantly make xmpp 256 times more secure
  412. larma Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext
  413. Zash I'll get right to work hacking into every existing deployment and invalidating all credentials!
  414. jonas’ Zash, easy!
  415. jonas’ just publish mod_av which claims to enable A/V support immediately
  416. Zash larma, correct in the case of Prosody 0.12. Hashed credentials are stored in one or the other and can't be changed afterwards.
  417. stpeter has joined
  418. larma Zash, which means *proper* setups have no upgrade path to sha-256, which is exactly what I'd like to tackle somehow before we blame everyone for not implementing things that can't be upgraded on anyway
  419. Zash There's no upgrade path anyways
  420. larma There could be, we just don't have one yet.
  421. larma even if the upgrade only happens when you do your next password change, that's an upgrade path
  422. larma or it happens when you next sign in with a device that does PLAIN
  423. larma (which happens as soon as a client only supports PLAIN and SHA-256 and your server is still on SHA-1)
  424. larma however the upgrade path requires a way for the server to signal that they currently don't have the sha256 hash and thus can't use SCRAM-SHA-256
  425. larma and this should be per user.
  426. jonas’ which is indistinguishable from a downgrade attack, by the way.
  427. Zash this
  428. larma a downgrade attack through an authenticated channel?
  429. Zash If I somehow steal your cert+privkey and get your clients to connect to me and I only offer PLAIN, I can steal their passwords.
  430. larma only if they have the passwod in cleartext, which they shouldn't if your server supported scram
  431. larma I was talking about a newly connecting client, and that would be fooled by such attack anyways
  432. jonas’ FTR, we do have: https://tools.ietf.org/html/rfc6120#section-6.5.9
  433. larma also when I can get you to connect to me without -PLUS I can already steal all your messages from MAM which is probably worth way more than the password...
  434. jonas’ given that the initial data in SCRAM is enough to identify the user, servers could reply with mechanism-too-weak on a migrated account
  435. jonas’ not sure what to do with a non-migrated account though
  436. Zash Is there an "upgrade required"?
  437. larma jonas’, but then I can probe users again
  438. jonas’ larma, yes
  439. larma also mechanism-too-weak will probably fail on clients
  440. jonas’ can I swing my "arrogant developer hammer" again? ;)
  441. larma assuming clients exist that only do plain and sha-1 and server supports plain,sha-1 and sha-256 in general, but for a specific account only plain+sha-256 (because account was upgraded), the client should try sha-1 and then would get <mechanism-too-weak/> which shouldn't be interpreted as "try plain instead"
  442. stpeter has left
  443. larma = in this upgrade path a proper client would stop working for no good reason.
  444. mukt2 has left
  445. mukt2 has joined
  446. Neustradamus_ larma: if an XMPP client has only SCRAM-SHA-1 and server has PLAIN and SCRAM-SHA-256, it fails.
  447. Maranda has left
  448. Maranda has joined
  449. Neustradamus_ Note that an XMPP client can have in settings : force PLAIN password, ...
  450. Neustradamus_ Screenshots: - https://i.ibb.co/RzgYTRS/psi-plus-allow-plaintext-authentication.png - https://i.ibb.co/n3vxnyT/psi-plus-encrypt-connection.png
  451. Neustradamus_ Gajim via nbxmpp has SCRAM-SHA-256(-PLUS) and SCRAM-SHA-1(-PLUS) https://dev.gajim.org/gajim/python-nbxmpp/commit/f2a203387891455c052d44f8b1ceae711773cb81
  452. Neustradamus_ lovetox: ^
  453. sonny has left
  454. sonny has joined
  455. sonny has left
  456. sonny has joined
  457. mukt2 has left
  458. larma Neustradamus_, I think you are missing the point here really. There is no client that does not support PLAIN. And it's unlikely there ever will be.
  459. mukt2 has joined
  460. calvin has joined
  461. LNJ has joined
  462. Dele Olajide has left
  463. mukt2 has left
  464. calvin has left
  465. eta has left
  466. eta has joined
  467. mukt2 has joined
  468. Ge0rG has left
  469. Maranda > Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext Why not that's what I exactly do
  470. Maranda > Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext Why not that's what I exactly do larma
  471. Ge0rG has joined
  472. Neustradamus_ Maranda: How it is done with Metronome and your XMPP server?
  473. Maranda I just said that I generate server keys for each hashing algorythm I support for SCRAM
  474. larma Maranda, but then you don't have the advantage of the more secure hashing algorithm to protect password from cracking (if password database is leaked). Because I can just attack the hash with the lowest security (sha-1)
  475. moparisthebest has joined
  476. larma which kind of is the point of using sha-256 over sha-1
  477. Maranda And then most bussness infrastructures out there do still have the requirement to have at least reversible encrypted passwords, so the whole argument is kind of "a good purpose" one but again all it matters is safety and trust of the who deals with 'em.
  478. Zash Could someone find a cryptomath wizard and ask them to calculate the ratio of securityness between sha-256 and sha-1
  479. Zash ... and then we just increase the minimum iteration count by that ratio!!!
  480. Zash bam, sha1 forever
  481. pdurbin has joined
  482. larma .... that's not how this works...
  483. Maranda larma: i'd ditch all other mechanisms for scram-sha-512-plus already just get all clients to support that and channel binding and we have a deal
  484. larma Maranda, sounds like a great plan, except it doesn't work because legacy clients will always be around.
  485. Maranda larma: oh really? 😘
  486. larma 😉
  487. Zash (and scram-sha-512-plus is undefined and doesn't exist)
  488. larma can we do scram-argon2d-plus please?
  489. Zash sure
  490. larma *Argon2id
  491. Zash I the SCRAM construct doesn't depend that much on PBKDF2
  492. Zash The SCRAM construct doesn't depend that much on PBKDF2
  493. Zash any ƒ(password, salt, iterations) → blob would do in theory
  494. Zash Gets weird if it takes other parameters than those tho
  495. larma well, it already does that
  496. larma SCRAM-SHA-256 has ƒ(password, salt, iterations) = sha2(32, password, salt, iterations)
  497. Zash You mean PBKDF2(hmac-sha-256, ..., output size)
  498. karoshi has left
  499. karoshi has joined
  500. Zash Hi() is a special case of PBKDF2 with some predefined parameters
  501. larma whatever 😉 sha-256 already is sha-2 + 32 byte. So any SCRAM-ARGON-X could do the same
  502. sonny has left
  503. sonny has joined
  504. sonny has left
  505. sonny has joined
  506. larma but probably not gonna happen soonish anyway 🙁
  507. larma probably never
  508. Zash Not with that attitude :P
  509. larma would be too good if we weren't discussing upgrading to something that's already outdated...
  510. Zash SHA-2 isn't outdated?
  511. larma there is SHA-3, so by definition SHA-2 is outdated
  512. Zash SHA-2 isn't broken yet afaik
  513. larma yeah, wasn't saying broken
  514. larma sha-1 also isn't broken for our usage
  515. Zash I thought the point of picking a SHA-3 was to have something in case the very foundational concepts that SHA-2 (and SHA-1) are built on were broken, and that's not happen yet
  516. Zash Yeah, so why the push to SHA-2?
  517. Zash We gain nothing but pain atm
  518. larma It's not me who is pushing 😉
  519. larma I am just pushing for an upgrade path, so we can handle it should it become necessary
  520. larma plan the upgrade now so it can happen in 10 years or so
  521. larma don't do another 12-byte IV 😀
  522. Zash Invent a better SCRAM, one that can tell the client in a secure manner "yo, you gonna need to reset your password for security upgrade reasons"
  523. jonas’ Zash, you can do that with SASL2 after successfully authenticating with SCRAM first
  524. Zash Sure
  525. stpeter has joined
  526. Neustradamus_ SCRAM SHA-3 is planned yes
  527. larma And SCRAM Argon2id?
  528. pdurbin has left
  529. calvin has joined
  530. Zash It's tricky since you don't know at the time when you're offering mechanisms whether the user supports them.
  531. !XSF_Martin has left
  532. !XSF_Martin has joined
  533. jonas’ we’ve been at this point two hours ago
  534. Zash :)
  535. Zash And weeks/months ago.
  536. larma maybe we should have clients propose mechanism to the server not the other way round
  537. Zash I'm just copying from a script actually :P
  538. jonas’ larma, and then what? you can still probe by looking at the mechanisms accepted for $randomUUID vs. $guessedUsername
  539. larma it adds complexity to the attack
  540. jonas’ not much though
  541. Maranda Oh heaven so this is about brute forcing SCRAM?
  542. larma maybe we need a stateful authentication protocol and abandon passwords after first login
  543. jonas’ Maranda, no
  544. jonas’ larma, like the thing dave wrote?
  545. Maranda And/or possibility of
  546. jonas’ also, I’m all for it
  547. jonas’ Maranda, no
  548. Maranda jonas’: better
  549. Jeybe has left
  550. Maranda has a log tail which could have been more interesting in that case 👨‍💻
  551. larma jonas’, not sure about the exact protocol, but yeah something that gives you a per-client token that can be stored by the client and also can be revoked if necessary.
  552. Zash OAuth?
  553. larma Alternatively we could only announce PLAIN in mechanisms, than get told the mechanisms supported by server *after* succesful login and be able to use SCRAM-* on later logins, ignoring that only PLAIN is announced.
  554. Zash What was that combined auth and stream resumption token spec called?
  555. Zash larma, haha
  556. larma Zash, 397?
  557. Zash That's the one
  558. jonas’ https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00 that’s the one I meant
  559. andrey.g has left
  560. larma E_TOO_MANY_PROTOCOLS
  561. Zash Bring back https://xmpp.org/extensions/xep-0078.html !!!!11! /s
  562. larma Zash, IIRC in OAuth the client has to register a-priori with the service to receive the client-key, no?
  563. Zash It Depends!
  564. larma which is also why OAuth for email got no traction. email clients only support Google and Microsoft for OAuth
  565. Zash If you use deprecated parts of OAuth you can get a token using a password.
  566. larma Ah, right. But that's not how it's supposed to be.
  567. larma Because you can't make use of service specific login pages that do 2fa and alike then.
  568. stpeter has left
  569. Zash If you're going to use OAuth "as it's supposed to be" then you can't have nice things, only browser and web services.
  570. larma well non-browser clients can open a web browser to authenticate than callback to the client
  571. larma that's how thunderbird does googlemail
  572. Zash from another part of my script, I say "if I have to open a browser then I hate it"
  573. larma that's ok, you can still do PLAIN
  574. larma with a single-use password you somehow retrieved from your service
  575. larma (probably using a browser)
  576. Dele Olajide has joined
  577. robertooo has left
  578. robertooo has joined
  579. govanify has left
  580. govanify has joined
  581. govanify has left
  582. govanify has joined
  583. adiaholic_ has left
  584. adiaholic_ has joined
  585. andrey.g has joined
  586. waqas has joined
  587. dwd XEP-0397 is CLIENTKEY, but the SASL bits live in the I-D. The other thing you could do is XEP-0257 (or similar).
  588. emus has left
  589. emus has joined
  590. larma dwd, xep-0397 doesn't have the counter part built-in. And it's also not asking for TOTP (which probably shouldn't have been in clientkey anyway)
  591. dwd Oh, wait. Wrong XEP.
  592. larma oh, and xep-0397 also doesn't have expiry
  593. dwd XEP-0399.
  594. larma I kind of wonder why all the TOTP is part of those XEPs
  595. larma seems kind of arbitrary to put it in there, as it could be completely ignored
  596. larma I see it makes things easier if TOTP is required, but it also works and makes sense without TOTP
  597. andy has left
  598. larma but in general, I'd rather see 399 being pushed than SCRAM-SHA-256
  599. dwd For '399? That was the driving factor for Surevine, as it happens.
  600. larma I mean TOTP is obviously non-normative in '399, so I am fine with that, but I'd probably want to get rid of that before moving it to draft.
  601. dwd So we had a requirement from the market for second-factor, based on TOTP. So we had SASL2+TOTP (in Openfire, code public), but it was a browser-based client, so we needed to avoid forcing the user to re-enter TOTP every time they refreshed, hence '399.
  602. larma Also CLIENT-KEY and CLIENT-KEY-PLUS would need to be IANA registered first, right?
  603. dwd The '399 code is also public, but it's an earlier design.
  604. larma dwd, yeah I guessed that TOTP was the driving force here 😉
  605. dwd larma, Sorta. Eventually. But they're in I-D form now.
  606. dwd larma, But I wouldn't remove 2FA entirely from '399 - while CLIENTKEY isn't dependent on it, it feels important that a client shouldn't ordinarily get a TOTP challenge when using CLIENTKEY, since the client installation has become the second factor, sort of.
  607. larma Yes, I am fine with mentioning that, basically the 4th sentence in §2.
  608. larma Also probably the other way round, mention it in 400, no?
  609. larma *mention '399 in '400
  610. karoshi has left
  611. karoshi has joined
  612. Yagiza has left
  613. andy has joined
  614. paul has left
  615. Zash has left
  616. Zash has joined
  617. sonny has left
  618. sonny has joined
  619. sonny has left
  620. sonny has joined
  621. Zash has left
  622. Zash has joined
  623. APach has left
  624. APach has joined
  625. mukt2 has left
  626. gav has left
  627. Mikaela has left
  628. pdurbin has joined
  629. govanify has left
  630. mukt2 has joined
  631. govanify has joined
  632. pdurbin has left
  633. debacle has left
  634. debacle has joined
  635. stpeter has joined
  636. eta has left
  637. eta has joined
  638. andy has left
  639. sonny has left
  640. sonny has joined
  641. sonny has left
  642. sonny has joined
  643. mukt2 has left
  644. mukt2 has joined
  645. andy has joined
  646. Yagiza has joined
  647. Dele Olajide has left
  648. andy has left
  649. arc has left
  650. arc has joined
  651. arc has left
  652. arc has joined
  653. arc has left
  654. arc has joined
  655. andy has joined
  656. Wojtek has joined
  657. Jeybe has joined
  658. mukt2 has left
  659. mukt2 has joined
  660. karoshi has left
  661. karoshi has joined
  662. paul has joined
  663. xsf has joined
  664. werdan has joined
  665. Jeybe has left
  666. Jeybe has joined
  667. sonny has left
  668. sonny has joined
  669. sonny has left
  670. sonny has joined
  671. Wojtek has left
  672. Wojtek has joined
  673. Nekit has left
  674. Nekit has joined
  675. Jeybe has left
  676. Jeybe has joined
  677. Wojtek has left
  678. Wojtek has joined
  679. nyco has left
  680. nyco has joined
  681. arc has left
  682. arc has joined
  683. krauq has left
  684. krauq has joined
  685. Steve Kille has left
  686. Nekit has left
  687. Steve Kille has joined
  688. rion has left
  689. rion has joined
  690. krauq has left
  691. krauq has joined
  692. Nekit has joined
  693. karoshi has left
  694. karoshi has joined
  695. Mikaela has joined
  696. mukt2 has left
  697. debacle has left
  698. mukt2 has joined
  699. adiaholic_ has left
  700. adiaholic_ has joined
  701. Nekit has left
  702. pdurbin has joined
  703. Yagiza has left
  704. pdurbin has left
  705. karoshi has left
  706. karoshi has joined
  707. mukt2 has left
  708. mukt2 has joined
  709. sonny has left
  710. sonny has joined
  711. sonny has left
  712. sonny has joined
  713. mukt2 has left
  714. mukt2 has joined
  715. nyco has left
  716. karoshi has left
  717. karoshi has joined
  718. govanify has left
  719. govanify has joined
  720. sonny has left
  721. sonny has joined
  722. govanify has left
  723. Bezi has joined
  724. govanify has joined
  725. debacle has joined
  726. debacle has left
  727. debacle has joined
  728. nyco has joined
  729. Nekit has joined
  730. Dele Olajide has joined
  731. Dele Olajide has left
  732. adiaholic_ has left
  733. adiaholic_ has joined
  734. govanify has left
  735. govanify has joined
  736. karoshi has left
  737. Seve has left
  738. Vaulor has left
  739. Vaulor has joined
  740. Seve has joined
  741. Andrzej has left
  742. karoshi has joined
  743. eta has left
  744. eta has joined
  745. lorddavidiii has left
  746. nyco has left
  747. xsf has left
  748. xsf has joined
  749. nyco has joined
  750. pdurbin has joined
  751. nyco has left
  752. DebXWoody has left
  753. mukt2 has left
  754. mukt2 has joined
  755. pdurbin has left
  756. arc has left
  757. arc has joined
  758. nyco has joined
  759. adiaholic_ has left
  760. adiaholic_ has joined
  761. mukt2 has left
  762. arc has left
  763. mukt2 has joined
  764. arc has joined
  765. Tobias has left
  766. Mikaela has left
  767. Daniel has left
  768. werdan has left
  769. Daniel has joined
  770. goffi has left
  771. rion has left
  772. goffi has joined
  773. goffi has left
  774. Daniel has left
  775. Daniel has joined
  776. karoshi has left
  777. karoshi has joined
  778. Mikaela has joined
  779. wurstsalat has left
  780. Mikaela has left
  781. Mikaela has joined
  782. paul has left
  783. paul has joined
  784. wurstsalat has joined
  785. mukt2 has left
  786. mukt2 has joined
  787. robertooo has left
  788. robertooo has joined
  789. calvin has left
  790. lorddavidiii has joined
  791. eta has left
  792. eta has joined
  793. Jeybe has left
  794. Jeybe has joined
  795. Daniel has left
  796. arc has left
  797. arc has joined
  798. Daniel has joined
  799. Mikaela has left
  800. arc has left
  801. arc has joined
  802. LNJ has left
  803. lorddavidiii has left
  804. pdurbin has joined
  805. sonny has left
  806. sonny has joined
  807. sonny has left
  808. sonny has joined
  809. Jeybe has left
  810. Jeybe has joined
  811. mimi89999 has left
  812. mimi89999 has joined
  813. moparisthebest has left
  814. moparisthebest has joined
  815. Jeybe has left
  816. pdurbin has left
  817. mukt2 has left
  818. andy has left
  819. mukt2 has joined
  820. Wojtek has left
  821. Wojtek has joined
  822. Wojtek has left
  823. robertooo has left
  824. karoshi has left
  825. karoshi has joined
  826. arc has left
  827. arc has joined
  828. Daniel has left
  829. Nekit has left
  830. Daniel has joined
  831. arc has left
  832. arc has joined
  833. Wojtek has joined
  834. Wojtek has left
  835. debacle has left
  836. sonny has left
  837. sonny has joined
  838. sonny has left
  839. sonny has joined
  840. rion has joined
  841. emus has left
  842. Wojtek has joined
  843. Wojtek has left
  844. Wojtek has joined
  845. Wojtek has left
  846. stpeter has left
  847. lskdjf has left
  848. mukt2 has left
  849. lskdjf has joined
  850. Seve has left
  851. mukt2 has joined
  852. bear has left
  853. Wojtek has joined
  854. mimi89999 has left
  855. mimi89999 has joined
  856. waqas has left
  857. stpeter has joined
  858. mimi89999 has left
  859. mimi89999 has joined
  860. calvin has joined
  861. arc has left
  862. arc has joined