writing.exchange is one of the many independent Mastodon servers you can use to participate in the fediverse.
A small, intentional community for poets, authors, and every kind of writer.

Administered by:

Server stats:

346
active users

#passkeys

7 posts6 participants0 posts today
Replied in thread

@zak @zenbrowser : a still unfixed vulnerability: if NOT using Touch ID, on some websites you may be able to sign in using a passkey WITHOUT authenticating locally - using biometrics or your passcode (screen unlock code).

⛓️💥 This vulnerability also exists WITH Touch ID set up, provided that "Password Autofill" is disabled.

BTW this vulnerability also permits access to:
icloud.com
account.apple.com
(When asked to provide your fingerprint, tap the X at the top right and tap in the "Email" field one more time).

This is a HUGE risk for people who do not want to use biometrics: if a thief grabs their iPhone when unlocked, or watches them enter their passcode and later steals their iPhone, the thief can use ALL of the owner's passwords and some of their passkeys stored in the "Passwords" app (formerly known as iCloud Keychain).

🎬 This increases the risks of theft as shown by WSJ's Joanna Stern in youtube.com/watch?v=QUYODQB_2wQ.

👶 In addition, a (grand) child or anyone else who (shortly) borrows your iPhone/iPad may have access to more of your cloud-accounts than you're aware of.

🔧 Workaround if you don't want to use biometrics to unlock your iPhone/iPad (this does not fix any problem if a thief learns (or successfully guesses) your passcode (screen unlock PIN or password):

• Set up a Touch ID anyway, for example for your left pinky finger (if you're righthanded)

• Disable "iPhone Unlock" in "Touch ID and Passcode" (visible in the first screenshot).

• Use a safer password manager (such as KeePassium) than the Apple "Passwords" app (iCloud KeyChain).

🚨 In any case:

• Make sure that "Password Autofill" (in settings -> "Touch ID and Passcode") is set to ENABLED;

• When you enter your passcode in a public place (such as a bar, bus or train), make very sure that nobody gets to see you enter it.

Any #passkeys experts around here? My government’s IT service maintains that they are correct when they use the term “passkey” to mean “hardware security device” (YubiKey and stuff,) and that I’m wrong for (1) saying those have never been called “passkeys” before the real passkeys were introduced and (2) expecting passkey support to mean the software passkeys provided by Safari or 1Password. #passkey

Better late than never... It published instantly to YouTube, but now you can check out our Episode 338 "AI Security Concerns" from October 23, 2024 on both edtechSR.com and Substack!
edtechsr.com/2025/02/14/edtech

The Substack version contains BOTH links we discussed during the episode AND those we found but didn't have time to talk about:
edtechsr.substack.com/p/edtech

#edtechSR#AI#edtech

Passkey/password bug: iOS 18.3.1

Ook in iOS versie 18.3.1 is de eerder door mij gemelde iCloud KeyChain (*) kwetsbaarheid nog niet gerepareerd (eerder schreef ik hierover, Engelstalig: infosec.exchange/@ErikvanStrat).

(*) Tegenwoordig is dat de app genaamd "Wachtwoorden" (of "Passwords").

De kwetsbaarheid bestaat indien:

• De eigenaar een "passcode" (pincode of wachtwoord) gebruikt om de iPhone of iPad te ontgrendelen - en er GÉÉN biometrie is geconfigureerd;

ofwel:

• De gebruiker wel biometrie kan gebruiken om het scherm te ontgrendelen, doch in 'Instellingen' > 'Touch ID en toegangscode' de instelling "Autom. invullen wachtw." is UITgezet.

Zie onderstaande screenshots (Engelstalig in infosec.exchange/@ErikvanStrat). Meer info ziet u door op "Alt" in de plaatjes te drukken.

Probleem: iedereen met toegang tot de ontgrendelde iPhone of iPad kan dan, *zonder* opnieuw lokaal te hoeven authenticeren:

1) Op elke website inloggen waarvan het user-ID en wachtwoord in iCloud Keychain zijn opgeslagen;

2) Met passkeys op enkele specifieke websites inloggen (waaronder account.apple.com en icloud.com), namelijk als volgt:

a) Open de website;
b) Druk op "Inloggen";
c) Druk op de "x" rechts bovenaan de pop-up die verschijnt (in de onderste schermhelft);
d) Druk kort in het veld waar om het e-mailadres gevraagd wordt;
e) Druk op de knop "gebruik passkey".

Risico: uitlenen van een unlocked iDevice (o.a. aan kinderen) maar ook diefstal nadat de passcode is afgekeken. Of als de dief geen passcode heeft, als deze wacht tot de eerstvolgende iOS/iPadOS kwetsbaarheid bekend wordt waarbij de schermontgrendeling omzeild kan worden.

Als u ze nog niet gezien heeft, bekijk in elk geval de eerste van de volgende twee video's van Joanna Stern (van de Wall Street Journal):
youtube.com/watch?v=QUYODQB_2wQ
youtube.com/watch?v=tCfb9Wizq9Q

Killing all my #PassKeys with fire. What an awful user experience, especially the fact that you can't use a device with a passkey for a site as a second factor for that same site, just one or the other, meaning if you're on a device that doesn't support passkeys, you have to fall back to MITM-able TOTP or have a second device for U2F.

Replied in thread

@vPurple : because I'm a security guy who wants to help others make the best of things (even if it regularly feels like pulling my hair out).

Most people will *not* install an alternative OS on their phone.

And I use main stream stuff to be able to tell big tech when things suck (unfortunately they're mostly deaf).

iCloud Keychain passkeys and passwords vulnerability: infosec.exchange/@ErikvanStrat

Android passkeys vulns: infosec.exchange/@ErikvanStrat (after publishing seclists.org/fulldisclosure/20).

OTOH Mozilla eventually fixed a bug in Firefox for iOS/iPadOS that I reported (under specific, non-exceptional, circumstances a padlock was shown while http was being used: infosec.exchange/@ErikvanStrat).

@Tutanota

Replied in thread

@eelcoa : jazeker, maar heel veel wachtwoordmanagers doen dat standaard niet.

Bovendien moeten internetters zich niet laten misleiden om, als de wachtwoordmanager nergens mee komt, zoals voor iets als:

https://UBN-identiteits-verificatie·com

(UBN = UwBankNaam)

dan maar zelf de inloggegevens voor hun bank in de wachtwoordmanager op te zoeken.

Ten slotte checken wachtwoordmanagers zelden of een website van https gebruik maakt.

Passkeys hebben geen van de drie bovengenoemde nadelen, maar wel weer een heel stel andere.

Waarom 2FA/MFA niet tegen phishing beschermen, Engelstalig (het zóvéélste voorbeeld, deze van afgelopen week: bleepingcomputer.com/news/secu). Iets eerder, meer uitleg: securityweek.com/mfa-isnt-fail.

Veilig inloggen: security.nl/posting/840236/.

Beknopt (Engelstalig) tips voor wachtwoordmanagers onder Android, iOS en iPadOS: infosec.exchange/@ErikvanStrat.

Android screenshot bij gebruik van KeePassDX: infosec.exchange/@ErikvanStrat.

Safari onder iOS/iPadOS laten waarschuwen als (ook heel eventjes tussendoor) http gebruikt wordt: infosec.exchange/@ErikvanStrat.

Passkeys voor leken (NL): security.nl/posting/798699

Ptoblemen met passkeys: infosec.exchange/@ErikvanStrat.

@maartjeS

BleepingComputer · Hackers spoof Microsoft ADFS login pages to steal credentialsBy Bill Toulas
Replied in thread

@thomasbosboom : I reported the passkkey (and password) bug privately to Apple in the summer of 2023. Even after providing a near endless amount of screenshots and other proof, Apple said it's a wontfix.

The basic issue is that, if the user does not use biometrics to unlock their iPhone or iPad, they are NOT asked to enter their (screen unlock) passcode to use passwords from iCloud keychain.

IMO that on itself is already insane (considering [1]). Many people do not use biometrics.

If no bio is used (and even if it is) there are specific circumstances where someone with access to an unlocked iDevice (think of children) can use passkeys without any local authentication.

Just tested using iOS v18.3: with my iPhone unlocked, I can log in to icloud.com and (fixed URL 20:48 UTC) account.apple.com using the passkey on my iPhone WITHOUT providing any credentials.

If @rmondello reads this: thank you for adding the Safari "Not Secure Connection Warning"!

Even if it not enabled by default, this http warning should help protect against EvilTwin attacks (such as described in bleepingcomputer.com/news/secu).

[1] See WSJ's Joanna Stern in youtube.com/watch?v=QUYODQB_2wQ and youtube.com/watch?v=tCfb9Wizq9Q. And no, I do not believe that Stolen Device Protection is a good idea. Most people will not use it.

@roman78

icloud.comiCloudLog in to iCloud to access your photos, mail, notes, documents and more. Sign in with your Apple Account or create a new account to start using Apple services.
Replied in thread

@thomasbosboom : onder Android is het risico niet denkbeeldig dat je al jouw passkeys kwijtraakt of dat ze niet syncroniseren naar een ander toestel.

Onder iOS en iPadOS zijn er omstandigheden waarbij iemand, die een ontgrendelde iPhond of iPad in handen heeft (zoals een dief die zo'n apparaat uit jouw handen grist op het moment dat je het gebruikt), met 0FA van jouw iCloud wachtwoorden en passkeys gebruik kan maken.

infosec.exchange/@ErikvanStrat

Allemaal "wontfix" door Apple/Google en het Chromium team.

@roman78

Infosec ExchangeErik van Straten (@ErikvanStraten@infosec.exchange)Attached: 1 image @ryanrowcliffe : thanks for your kind response. I fully agree that if software (instead of the user) checks the website name (domain name) before submitting *any* credentials, is a perfect solution for most of the "fake site" attacks (except https://infosec.exchange/@ErikvanStraten/112914047006977222). Unfortunately passkey implementations are insufficiently mature for the masses (I'm not talking about my *personal* situation). And I do like passkeys, but they must work flawlessly before I'm going to advise anyone to use them. People who never used a pw manager will *not* install one to use passkeys. On their tablets and smartphones (marktshare increasing) they'll use Apple's or Google's. During my research I found at least three ways to fully unexpectedly lose access to part or all of one's Android passkeys: 1) The unexplicable and fearsome Android screen reading "Your encrypted data is locked on this device" (Google it or see https://infosec.exchange/@ErikvanStraten/113730072998238596) when trying to use passkeys. This is a long time bug that, afaik, has not been fixed. 2) For privacy reasons, setting up a passphrase for Chrome sync is a good idea. However, if you ever want to change or remove that passphrase, Google directs you to the bottom of https://chrome.google.com/sync (see the screenshot below). Tapping "Delete data" will delete ALL of your passkeys (on all your Android devices) without warning. Note: this text notably is the "fix" made by Adam Langley in response to my post to https://seclists.org/fulldisclosure/2024/Feb/15 (after wasting a long time after my bugreports to the Google and Chrome team): before it read "This won't delete any data from your devices". Note: it appears to be a misconception that passkeys are synced from your device(s) to the cloud. They're cloud-based and sync to your devices. Google stores the encryption keys and, afaik, generates them on their servers. Furthermore, bugsolving is hampered by the fact that both Google and (separate) Chrome teams have to handle them. 3) If you have more than one Android device, you may run into the situation where your passkey's private keys are encrypted using *different* encryption keys. They will sync fine to other devices, but are unusable on them (see my FD post). I've not tested this for quite some time, so this issue may have been fixed (if Google did, they didn't bother to notify me). Google online help is horrific: https://infosec.exchange/@ErikvanStraten/113730722652512878. Edited 12:10 UTC to add: a somewhat acceptable translation from Dutch to English of my writeup "Passkeys for laymen" can be seen by opening https://www-security-nl.translate.goog/posting/798699/Passkeys+voor+leken?_x_tr_sl=nl&_x_tr_tl=en&_x_tr_hl=nl (it appears to work in Chrome, looks like a phishing link and has a certificate with a zillion of different domain names 🤔). The original article, in Dutch, can be seen in https://www.security.nl/posting/798699/Passkeys+voor+leken. 🧵1/2 @agl #Passkeys #Immature #ImplementationFlaws