ewiley posted:

https://twitter.com/GossiTheDog/status/1163753873351356417?s=20

Hmm what's the over/under this is a secfuck or just an IT outage.

Volmarias posted:

My bank just magnanimously informed me via email that my contactless credit card that I never wanted nor asked for is now on the way since I'm such a good customer.

How currently hosed is this technology and do I have to wrap my card in tinfoil now?

Lain Iwakura posted:

Tap is better than chip because you’re not having liability shifted to you.

Volmarias posted:

My bank just magnanimously informed me via email that my contactless credit card that I never wanted nor asked for is now on the way since I'm such a good customer.

How currently hosed is this technology and do I have to wrap my card in tinfoil now?

Shaggar posted:

a bunch of wallets advertise NFC protection but I have no idea if any of it is legit.

haveblue posted:

my wallet breaks my building's security badge (gf gifted it without checking first) so it works that much. no idea if it would stop an intentional attack with a stronger antenna

Shaggar posted:

a bunch of wallets advertise NFC protection but I have no idea if any of it is legit.

Carbon dioxide posted:

Screenshot for when they delete the tweet

BMX Ninja posted:

I used to work for a company that was hired by an intermediary to pentest Virgin's sites, and sent this to a pal who still does.

Based on how they described the past few days it seems that advertising how bad your security practices are on social media is open season to hackers, ethical or otherwise. Who knew?

It's been a few years since I did any work for them, but at the time anything that couldn't be mitigated by updating to a newer product version was marked as 'won't fix'. That includes the passwords in plain text and low-entropy passwords that they've been aware of for a long long time.

IIRC the 10-character password limit was enforced, because at the time their lovely home routers also had a 10-char limit on the admin login, so they encouraged people to use the same password for both their router and their online services. Naturally, connecting to the router over wifi was HTTP-only and the password was sent as plaintext in a GET request.

Wiggly Wayne DDS posted:

the frankenmodem has some issues: https://www.nccgroup.trust/uk/about...for-a-backdoor/

haveblue posted:

it probably doesn't so much "block" it as create a bunch of noise and reflections that make the signal unusable

Wiggly Wayne DDS posted:

ya i mentioned the frankenmodem a few threads back and it shows their approach to everything:

the frankenmodem has some issues: https://www.nccgroup.trust/uk/about...for-a-backdoor/

real good read

Shame Boy posted:

near field stuff generally doesn't work the same as normal radio stuff, basically the card and the reader couple together like a transformer and the card "signals" the reader by adding and removing a load to its side of the transformer, so putting a conductive thing in between them really does "block" that coupling to an extent

Chalks posted:

also i'm not sure there's much point being paranoid about contactless skimming. it's been in common use for a long time now and i'm not sure i've ever heard of even a poc attack

Chalks posted:

yeah, contactless seems to get pretty easily blocked by other cards for me too.

also i'm not sure there's much point being paranoid about contactless skimming. it's been in common use for a long time now and i'm not sure i've ever heard of it happening

Raere posted:

Yeah, not sure I've ever heard of a real world case, just local news station features bringing on a local 'hacker' to demonstrate. Anecdotal, of course.

haveblue posted:

my wallet breaks my building's security badge (gf gifted it without checking first) so it works that much. no idea if it would stop an intentional attack with a stronger antenna

Hed posted:

Wasn't there a link to some email client (Outlook?) pre-fetching all the links in an email upthread?

I can't find anything about it for the life of me.

Hed posted:

Wasn't there a link to some email client (Outlook?) pre-fetching all the links in an email upthread?

I can't find anything about it for the life of me.

James Baud posted:

Might have been Microsoft thread, I read it as "MSFT-hosted OWA" when I saw it.

Chris Knight posted:

https://twitter.com/securinti/status/1159140784962015233

haveblue posted:

nfc is inductive? neat

Dehry posted:

https://twitter.com/zackwhittaker/status/1163465745877147650

Dehry posted:

https://twitter.com/zackwhittaker/status/1163465745877147650

ymgve posted:

*nervously clicks link, reads article, sees name of site, sighs in relief*

ymgve posted:

*nervously clicks link, reads article, sees name of site, sighs in relief*

ymgve posted:

*nervously clicks link, reads article, sees name of site, sighs in relief*

florida lan posted:

one of our customers, who is heavy on the "can you provide us with 'best practices'?" (aka "we have no confidence in what we're doing and hope our vendor will do free tech consulting for poo poo that isn't their product") train would like to add authentication to their APIs

we have several means of adding authentication, but for brevity, it probably makes most sense for them to use OIDC: their identity provider supports it, our implementation is generally robust and feature-complete, if a mass of inscrutable spaghetti code.

the customer security architect is adamantly against this, arguing that OIDC's (typical) use of plaintext ID tokens is anathema, and also the vague "it's not industry standard to use OIDC to secure APIs" with no supporting rationale whatsoever.

their solution to the unspeakable horror of plaintext ID tokens is to essentially roll their own protocol from bits of other poo poo, banking on their identity provider being able to issue encrypted JWT access tokens that contain identifying information. they will copy the encryption keys to the gateway proxies handling authentication and write their own custom code to handle JWE decryption using them to extract the identifying info. this is lovely in so many ways:
* rolling your own crypto libs (in a language i doubt they have much expertise in): always a good idea!
* living in a magical world where somehow decrypting a TLS stream to get plaintext is somehow less meaningfully secure than decrypting a TLS stream to get an encrypted token and then decrypting the token
* there's a decent chance the key used to do JWE is the same key the IDP uses for JWS, since it's fine for access tokens to be opaque and impossible to decrypt normally. nothing like increasing your attack surface for stealing a key that can then be used to mint valid ID/access tokens.
* the OIDC spec literally already provides for ID token encryption in a less stupid way (the client has its own key pair and registers the public key with the identity provider). granted, our client doesn't implement this (because everyone else is fine with TLS), but the customer sure as hell didn't bring it up

bonus tangentially related content: i am quite amused that the Azure OIDC implementation has taken the good step of providing client-specific and global unique identifiers that require different permissions (to prevent correlation of accounts across multiple OIDC users), but also mysteriously using plaintext access tokens that apparently include ALL available claims (including, but not limited to, the client-specific identifier, global identifier, and user email address) regardless of what was requested or authorized by the user. the ID tokens only containing authorized claims.

their github comments indicate that they intend to encrypt the access tokens sometime in the future.

ewiley posted: