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


  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


  361. jonas’


  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’


  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


  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


  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


  490. larma


  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


  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


  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


  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


  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