| 00:31.20 | *** join/#maemo KindOne (kindone@freenode/father-christmas/kindone) |
| 01:23.25 | *** join/#maemo KindTwo (kindone@freenode/father-christmas/kindone) |
| 01:58.12 | *** join/#maemo LauRoman|S (~LauRoman@5-14-89-111.residential.rdsnet.ro) |
| 02:17.52 | *** join/#maemo KindTwo (kindone@freenode/father-christmas/kindone) |
| 02:21.08 | *** join/#maemo KindOne (kindone@freenode/father-christmas/kindone) |
| 02:41.02 | *** join/#maemo sicelo (~sicelo@103.42.215.143) |
| 02:41.02 | *** join/#maemo sicelo (~sicelo@Maemo/community/ex-council/sicelo) |
| 02:41.50 | *** join/#maemo KindTwo (kindone@freenode/father-christmas/kindone) |
| 02:47.26 | *** join/#maemo tm (~sinnlos@unaffiliated/tm) |
| 03:33.55 | *** join/#maemo KindTwo (kindone@freenode/father-christmas/kindone) |
| 04:26.22 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:38.55 | *** join/#maemo APic (apic@apic.name) |
| 06:31.37 | brolin_empey | I love these lame applications that tell the user that their password has expired and needs to be changed but happily accept the expired password as the ânewâ password, such as the Web site for my current (since 2018 June) credit card provider who just expired my original password. |
| 06:34.36 | brolin_empey | Even Windows 2000 originally did this but Microsoft may have fixed it in one of the service packs. |
| 06:44.54 | *** join/#maemo Kabouik (~Kabouik@37.171.66.92) |
| 06:57.02 | *** join/#maemo Kabouik_ (~Kabouik@37.172.217.85) |
| 07:30.34 | luke-jr | brolin_empey: is there a legit use case for expiring passwords? |
| 07:51.10 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 07:57.12 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 08:24.24 | *** join/#maemo pagurus (~user@i59F7A075.versanet.de) |
| 08:38.37 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 08:47.37 | sixwheeledbeast | I fail to see the point in expiring passwords. Some companies have it as a policy. People are lazy you make it harder for people that use password management and the ones that dont care generally use the same password but change the last character. |
| 08:49.56 | sixwheeledbeast | As much as I hate biometrics it works for people that aren't interested. |
| 09:10.32 | *** join/#maemo Kabouik (~Kabouik@37.172.170.173) |
| 09:27.53 | *** join/#maemo chgvisual (~chgvisual@2a02:c7f:ca6:a700:fa21:d02e:eb04:e195) |
| 09:40.55 | Maxdamantus | I hate that most things even use passwords. |
| 09:42.54 | Maxdamantus | If a system is relyping on something like email as its actual authority (eg, systems where you can reset a password as long as you have access to an email address), a password is only really a convenience feature that makes it quicker to authorise (enter a memorised password instead of go through an email validation cycle). |
| 09:45.07 | Maxdamantus | Most sites should either just use email validation to log in. If it's something that someone is using frequently, then allow their broswser to remember the a long-lived session cookie, otherwise if they're using it infrequently, they're going to forget their password and go through an email validation cycle anyway. |
| 09:45.44 | Maxdamantus | s/either // |
| 10:05.56 | sixwheeledbeast | Your requiring the need for email and browser which maybe inconvenient. i don't want my browser to remember any cookies between sessions. |
| 10:08.27 | sixwheeledbeast | A password is providing a weak form of 2FA. If your email is compromised then you validate all sessions from there its a single point failure. |
| 10:10.24 | sixwheeledbeast | Also i believe we where referring to security more generally so logging into the system in the first place for example. |
| 10:25.27 | Maxdamantus | No. Allowing a password is a weakening of the system. 2FA is about requiring an *extra* requirement for authentication. Most password systems are about providing an *alternative* requirement for authentication. |
| 10:25.57 | Maxdamantus | Since most password systems allow you to authenticate if you've forgotten the password. |
| 10:26.14 | Maxdamantus | So the password is not actually required, it's just a way of access the system quicker. |
| 10:29.00 | Maxdamantus | 2FA requires 2 factors when authenticating. Password systems usually allow you to authenticate using only one factor (the password). Those systems also usually allow you to authenticate using the email, but they don't require you to authenticate using both. |
| 10:29.23 | Maxdamantus | So again, you've got two alternative ways of accessing the system, therefore it's strictly weaker. |
| 10:29.50 | Maxdamantus | and passwords seem like a very weak system. |
| 10:29.58 | Maxdamantus | Since people reuse passwords all the time. |
| 10:31.41 | Maxdamantus | > If your email is compromised then you validate all sessions from there its a single point failure. |
| 10:32.00 | Maxdamantus | Most password systems allow you to recover if you have access to email. |
| 10:32.38 | Maxdamantus | So by having a password, they're not protecting against that. |
| 10:33.43 | *** join/#maemo Kabouik (~Kabouik@147.99.221.196) |
| 10:37.40 | Maxdamantus | It's like allowing your friend into your house by opening the door for them (you are the primary authority), and then for convenience you can give them a door key. |
| 10:38.29 | Maxdamantus | Giving them a key is a weakening of security. |
| 10:38.43 | sixwheeledbeast | Not protecting no, but not providing access to everywhere else. If you have forgotten a password you would have to validate in the same way as registering the account in the first place and this would clear the password. |
| 10:39.46 | Maxdamantus | Right, so why not just require them to validate the same way each time they log in? |
| 10:40.04 | Maxdamantus | Instead of giving out extra keys that can be used to bypass the primary authority mechanism? |
| 10:40.33 | sixwheeledbeast | Well because it inconvenient just like never leaving your house so you can let your friend in. |
| 10:40.53 | sixwheeledbeast | to use your analogy |
| 10:40.59 | Maxdamantus | Right, so it's a convenience feature. It's a weakening of security. |
| 10:42.09 | *** join/#maemo Kabouik (~Kabouik@37.166.2.237) |
| 10:42.17 | sixwheeledbeast | I don't agree. It's systematically not compatible with people but itself it isn't a weakness IMO. |
| 10:42.34 | Maxdamantus | If it's a site that's used once every month or two, you might as well just have that initial validation as the way people log in, because it's likely that at that length of time, it's going to be more annoying trying to memorise a password than checking an email. |
| 10:43.49 | Maxdamantus | It's clearly a weakness. You still have the alternative way of authenticating (using email or whatever). Like the door analogy, you can still ask your friend to let you in. |
| 10:44.08 | Maxdamantus | But having a password/key is an extra vulnerability that can be exploited by others. |
| 10:44.56 | Maxdamantus | You could accidentally leave your key somewhere, or you could reuse a password, or you could enter your password into another website as you're trying to remember their password. |
| 10:45.44 | Maxdamantus | the password/key is a way of bypassing that primary authority mechanism (asking the friend, or verifying an email address) |
| 10:46.21 | sixwheeledbeast | As I say it not just about websites, you have security before you even get to a browser or email client. Using passwords incorrectly is down to the user not the method. |
| 10:47.08 | Maxdamantus | I'm not opposed to passwords overall. I just think most of them are useless. |
| 10:47.24 | Maxdamantus | There are relatively few things that should actually use passwords. That does not include most websites. |
| 10:48.44 | Maxdamantus | Most websites ultimately authenticate using email validation. Obviously if you're talking about access to an email account, or access to some system using ssh, you're not ultimately using email validation, so a password might make sense in those situations. |
| 10:49.14 | Maxdamantus | s/useless/useless and a security liability/ |
| 10:52.17 | *** join/#maemo Kabouik (~Kabouik@37.166.2.237) |
| 10:52.38 | sixwheeledbeast | You can't expect to validate every session via email on every site everytime you start a new browsing session. |
| 10:55.53 | Maxdamantus | Then remember the session. |
| 10:55.57 | sixwheeledbeast | The overhead created both ways would be ridiculous, also your email would not be protected via HTTPS. Leaving your browsing session open would be like leaving your front door open. |
| 10:56.07 | Maxdamantus | You mentioned password managers before. Where is the password being saved? |
| 10:56.25 | sixwheeledbeast | encypted somewhere else |
| 10:56.43 | Maxdamantus | Encrypted using what? |
| 10:57.08 | Maxdamantus | To the extent that most people use password management, it's just making the password accessible to the browser. |
| 10:57.37 | Maxdamantus | Might as well just store cookies instead. At least cookies are essentially forced to be randomly generated instead of potentially reused across different websites. |
| 10:58.13 | sixwheeledbeast | Encrypted with whatever the latest standard is an stored away from the session. |
| 10:58.15 | *** join/#maemo Kabouik (~Kabouik@37.166.2.237) |
| 10:58.45 | Maxdamantus | It would be fine if passwords were also required to be randomly generated (as often happens when people use more advanced password managers), but the point of a password is generally that the user is able to choose a common phrase that they can remember. There's nothing preventing them from reusing that phrase across different sites. |
| 10:59.04 | Maxdamantus | What's the difference between encrypting the password and encrypting the cookies? |
| 11:01.37 | Maxdamantus | (When I said "encrypted using what?" I meant: what is the source of the encryption key. You can't just encrypt something and then claim you've added security. If you store the encryption key next to the encrypted data, there's no added security.) |
| 11:02.03 | sixwheeledbeast | I am not saying the are perfect and that the system systematically helps people use them correctly. |
| 11:04.34 | Maxdamantus | If passwords are being encrypted using, eg, the user's OS password (so the actual key is encrypted using the user's OS password), browsers might as well just be doing the same thing with their cookie stores. If you forget your OS password, you lose access to your cookies. |
| 11:04.43 | sixwheeledbeast | Well you could be flexible the key can be anything:- psychical hardware, a piece of data, a "strong master password" that is only knowledge and not used elsewhere. |
| 11:04.44 | Maxdamantus | imo that's a pretty decent system. |
| 11:07.40 | *** join/#maemo Kabouik (~Kabouik@37.166.130.254) |
| 11:11.58 | sixwheeledbeast | Ultimately my ideal solution is a device combined with a password. (something I have and something I know). Which is pretty much what i have now, the random passwords that the manager makes up mean nothing to me or anyone. |
| 11:13.37 | Maxdamantus | Sure, so that's not really a password. It's still probably a weakening of the system, but it's not as weak as a typical password setup. |
| 11:13.55 | Maxdamantus | (typical password setup as in where the user remembers a password and types it in each time) |
| 11:14.25 | sixwheeledbeast | the issue with cookies is being tracked, you have no easy control over saving just the password and not the rest of the session to login quickly. |
| 11:16.21 | sixwheeledbeast | Yer i see what you mean from the POV of I am using the "Password" box as a "Key" so it's not really a "password" |
| 11:19.32 | sixwheeledbeast | I have never considered a password to be a "password" it's just a string of memorable characters. |
| 11:20.16 | Maxdamantus | also, in cases where websites do legitimately need to use actual passwords, I want there to be some sort of augmented PAKE system (eg, SRP or OPAQUE). It requires support from the web browser or OS, but it means it's not unsafe to, eg, reuse a password across multiple sites. |
| 11:21.34 | Maxdamantus | I imagine the main issue with PAKE is getting a UX that people learn to use properly, so they're informed that the browser/OS is asking for the password instead of the website. |
| 11:25.38 | *** join/#maemo Kabouik (~Kabouik@37.166.159.70) |
| 11:25.41 | Maxdamantus | imo SRP would also be suitable in place of ssh password authentication. |
| 11:25.48 | sixwheeledbeast | They are not going away, as other options all have equal flaws or implementation issues. |
| 11:43.42 | *** join/#maemo florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 12:00.08 | *** join/#maemo Kabouik (~Kabouik@37.166.197.196) |
| 12:30.47 | *** join/#maemo Kabouik (~Kabouik@37.166.243.108) |
| 12:33.46 | *** join/#maemo ^[_ (sid43445@gateway/web/irccloud.com/x-pevtobkvlxhxodcp) |
| 13:07.55 | *** join/#maemo eMHa (~mh@p4ff786b6.dip0.t-ipconnect.de) |
| 13:21.06 | *** join/#maemo Kabouik (~Kabouik@37.166.124.124) |
| 13:24.41 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 13:31.36 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 13:46.50 | *** join/#maemo sunshavi (~user@190.236.255.173) |
| 14:03.47 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 14:19.03 | *** join/#maemo Kabouik (~Kabouik@37.164.198.230) |
| 14:42.43 | *** join/#maemo Kabouik (~Kabouik@37.171.45.171) |
| 15:00.26 | *** join/#maemo troulouliou_div2 (~troulouli@185.228.19.147) |
| 15:00.37 | *** join/#maemo sunshavi (~user@190.236.255.173) |
| 15:00.45 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 15:08.59 | *** join/#maemo LauRoman|S (~LauRoman@5-14-89-111.residential.rdsnet.ro) |
| 15:36.29 | *** join/#maemo Kabouik (~Kabouik@37.171.45.171) |
| 16:56.02 | *** join/#maemo infobot (~infobot@96-86-209-102-static.hfc.comcastbusiness.net) |
| 16:56.02 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog http://maemo.cloud-7.de/irclogs/freenode/_maemo/latest.log.html | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 16:56.02 | *** mode/#maemo [+v infobot] by ChanServ |
| 19:19.40 | *** join/#maemo infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 19:19.40 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog http://maemo.cloud-7.de/irclogs/freenode/_maemo/latest.log.html | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 19:19.40 | *** mode/#maemo [+v infobot] by ChanServ |
| 19:39.36 | *** join/#maemo infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 19:39.36 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog http://maemo.cloud-7.de/irclogs/freenode/_maemo/latest.log.html | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 19:39.37 | *** mode/#maemo [+v infobot] by ChanServ |
| 19:44.05 | *** join/#maemo ced117 (~ced117@ghost.ced117.net) |
| 19:44.05 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 20:13.30 | *** join/#maemo l_bratch (~l_bratch@2a02:c28:a065:15:428d:5cff:fee5:10ee) |
| 21:27.53 | *** join/#maemo sunshavi (~user@190.236.255.173) |
| 22:01.58 | *** join/#maemo Kabouik (~Kabouik@2a01cb0080230100020af5fffe407ce3.ipv6.abo.wanadoo.fr) |
| 22:06.04 | *** join/#maemo sunshavi (~user@190.236.255.173) |
| 23:32.14 | *** join/#maemo Kilroo (~Kilroo@71.71.105.78) |