WTF Bites
-
They also did not ask for the full password every time but rather just 3-4 chars from it (say, "1st, 3rd and 4th char")
Wat. Unless they're storing hashes of those char combinations in advance (or have a very funky hashing algorithm), this means that your password lives somewhere in the clear.
Yeah, that was the
part of it. OTOH, I still feel safer with my bank doing that than with my bank using a simple 4 digits numerical code as sole authentication number (it may be hashed, but there are still only 10000 possibilities!).Also I wonder how difficult it would be to indeed use some weird implementation to do that properly, or at least not totally wrongly. Even storing (hashes of) all possible combinations might be feasible: they asked for 3 chars, out of say a max password length of 50 (which is quite generous) that's a bit more than 100 000 combinations. Since they're short you might use a short hash and might be able to store them with a couple of MB. The log of your connection history might be larger than that! (and if they restrict the password length to something smaller the number decreases very fast)
-
Obviously the reader doesn't contain any user-specific secret (that's in my card), but it does contain an algorithm to use that secret to generate the code that it prints on the screen.
I don't think so. From what I understand, all the secret sauce stuff is done inside the card's chip, so the reader just displays what the chip tells it to display.
-
@remi Wow. What a tangled mess of validating a purchase. Compared to how it works with swedish banks:
1: Enter card details.
2: Get sent to bank 2FA asking to verify with BankID or the bank-issued code device.
3: Enter PIN/code as appropriate.
4: Done.Also, BankID is the best invention. Secure verification of login and signing of documents to anything that implements it. Can be used for banks, healthcare, government sites, other misc site accounts...
-
@Zerosquare are you saying that a card contains an algorithm to generate a 6 (or is it 8? I don't remember...) digits code from the pin? Is it something that was already used for years before those card readers were made public? Because I don't remember my bank telling me (at the time) that only newer cards were usable with the readers (though of course they may have update the card silently without telling me). And I've had a card with pin since basically forever, including well before the internet existed (
well before it was widely known and used).Mind you, it might very well be that this algorithm is indeed what has always been used by e.g. ATMs or paiement terminals to validate purchases, and that the authentication card reader is just exposing a number that has always existed. Again, I don't know a thing about how cards work, so maybe.
-
Since they're short you might use a short hash and might be able to store them with a couple of MB.
Hashing a 3 digit number is no safer than storing a 3 digit number as plain text.
-
What a tangled mess of validating a purchase. Compared to how it works with swedish banks:
That's how is usually works as well. It's just my bank that recently switched to this weird mechanism with an intermediate hoop to jump through.
Though judging from messages I'm getting from another bank I have an account with, I fear that this is the way all banks are going to work and how they've decided to implement some EU regulation...
-
Hashing a 3 digit number is no safer than storing a 3 digit number as plain text.
I'm no security expert but I'd say it probably is safer. Not safe, mind you, nor safer by much, but still a tiny bit safer than not doing it.
-
@Zerosquare are you saying that a card contains an algorithm to generate a 6 (or is it 8? I don't remember...) digits code from the pin?
That's my understanding, yeah.
I don't remember my bank telling me (at the time) that only newer cards were usable with the readers (though of course they may have update the card silently without telling me).
Cards expire after a few years, so they get naturally replaced with newer, updated models. I think that feature has been implemented for longer than the usual renewal cycle duration.
Though judging from messages I'm getting from another bank I have an account with, I fear that this is the way all banks are going to work and how they've decided to implement some EU regulation...
Yes, there are new regulations since January. Banks (French ones, at least) have to offer something more secure than SMS for authentication. Most of them went "I know! I'll tell people to use our phone app!".
-
@Zerosquare said in WTF Bites:
That's my understanding, yeah.
I didn't think that was the case, but I also never really thought about it, so yeah, could very well be.
Still, back to the original point, I fear too many banks are just harnessing the
and doing as you say rather than using those kind of card readers:Most of them went "I know! I'll tell people to use our phone app!".
-
are you saying that a card contains an algorithm to generate a 6 (or is it 8? I don't remember...) digits code from the pin? Is it something that was already used for years before those card readers were made public?
The cards have a secret key that's been pre-shared with the bank. When you enter your PIN, the card verifies that it's the same PIN it knows about, then computes the hash of the key and a counter embedded in the card. The bank performs the same hash with a few different counter values. Usually (in a payment terminal) the whole cryptogram is used and the card also digitally signs the transaction details, but for users' convenience when using disconnected code generators like that only the last few digits of that first hash are used.
-
Hashing a 3 digit number is no safer than storing a 3 digit number as plain text.
I'm no security expert but I'd say it probably is safer. Not safe, mind you, nor safer by much, but still a tiny bit safer than not doing it.
Yes, roughly the same amount as ROT13 is safer.
-
@Zerosquare said in WTF Bites:
Plus there is the issue that it's another device that can break, or run out of batteries (not in a long time, probably, but still).
On the plus side, from my limited experience (two different banks, two different readers), they seem to be based on a generic design with no customization besides cosmetic stuff: using the reader from bank A with a card from bank B works. Which makes sense since all the actual security stuff is done inside the chip on the card ; the reader is just an interface. So it may be possible to borrow one if yours is lost or out of order.
Are you sure your devices aren't simply built by the same company? There's only a handful of companies building those things. For example, all the different bank card readers I have are made by Vasco / OneSpan.
Then do keep in mind that it's not just the appearance of the device which might be different, I've had it happen that one device could be used for authentication in another bank's website but not used for accepting a wire transfer. Apparently the firmware may sometimes follow a different number of steps which then causes a different response code.
@TwelveBaud said in WTF Bites:
are you saying that a card contains an algorithm to generate a 6 (or is it 8? I don't remember...) digits code from the pin? Is it something that was already used for years before those card readers were made public?
The cards have a secret key that's been pre-shared with the bank. When you enter your PIN, the card verifies that it's the same PIN it knows about, then computes the hash of the key and a counter embedded in the card. The bank performs the same hash with a few different counter values. Usually (in a payment terminal) the whole cryptogram is used and the card also digitally signs the transaction details, but for users' convenience when using disconnected code generators like that only the last few digits of that first hash are used.
AFAIK the chips used in bank cards are too cheap to use public key encryption, maybe because the cost was too prohibitive when bank cards were first being introduced and standardized. In my experience they only calculate a MAC (which is what you are describing).
Any signing I've seen in these kinds of transactions happens in the card reader / payment terminal itself. The device will check that it succesfully retreived a MAC and then sign all the transaction details + MAC to show that the transaction was done at an "authorized" spot by means of a private key built into the device. The bank will then verify the signature with a public key.
-
Are you sure your devices aren't simply built by the same company? There's only a handful of companies building those things. For example, all the different bank card readers I have are made by Vasco / OneSpan.
The one I can find conveniently appears to have been made by Xiring.
-
Are you sure your devices aren't simply built by the same company?
They probably are. Apart from the color scheme, they look identical.
-
Someone forgot to add the proper redirect on logging out from the timesheet methinks.
-
@Zerosquare are you saying that a card contains an algorithm to generate a 6 (or is it 8? I don't remember...) digits code from the pin? Is it something that was already used for years before those card readers were made public? Because I don't remember my bank telling me (at the time) that only newer cards were usable with the readers (though of course they may have update the card silently without telling me). And I've had a card with pin since basically forever, including well before the internet existed (
well before it was widely known and used).Mind you, it might very well be that this algorithm is indeed what has always been used by e.g. ATMs or paiement terminals to validate purchases, and that the authentication card reader is just exposing a number that has always existed. Again, I don't know a thing about how cards work, so maybe.
Not really, the BankID thing is an identification service connected to your national identity, that the banks developed together. It can be used for all sorts of identification/electronic signatures and isn't connected to a card.
You create your own signature PIN within the program, and the program contains it's own keypad to enter the PIN. The minimum length of the pin is 6 digits I think.
When you do purchases online, the bank requires you to authenticate the purchases through BankID. The authentication contains information about what it is you are authenticating and who the originator is. Usually, it's a payment processor but individual web stores can connect directly to bankid as well.
The card itself has a separate PIN for use in normal card transfers in brick-and-mortar locations.
-
Not really, the BankID thing...
... is an interesting thing, but only marginally (if at all) related to what I was talking about (since it doesn't exist in the countries I'm familiar with).
-
@Zerosquare said in WTF Bites:
Back to actual WTF bites:
Child tweets gibberish from US nuclear-agency account
The tweet “;l;;gmlxzssaw", posted to US Strategic Command's Twitter account, causes confusion.
STRATCOM does a lot more than nukes.
-
Hashing a 3 digit number is no safer than storing a 3 digit number as plain text.
I'm no security expert but I'd say it probably is safer. Not safe, mind you, nor safer by much, but still a tiny bit safer than not doing it.
Yes, roughly the same amount as ROT13 is safer.
Depends on if and how they salted the hashed 3 digits, though. But let's be serious. They're storing the password. Hopefully it's encrypted at rest. But let's be serious...
-
HTF did I manage to freeze the ribbon of a file explorer window?
I can select files in the main panel, switch directories in the directory tree, edit the address in the address bar, maximize and restore the window, etc. But clicking one of the tabs in the ribbon or trying to uncollapse it does nothing.
As a matter of fact, the ribbon is updating as I switch location, but it's otherwise completely unresponsive to clicks.
Fake edit: I managed to make it responsive again after I toggled it using this menu option:
-
That's... one way of avoiding SQL injection and XSS.
-
@error But one that's all too common, unfortunately.
-
I'm no security expert but I'd say it probably is safer. Not safe, mind you, nor safer by much, but still a tiny bit safer than not doing it.
About the same as jumping off a skyscraper with a tiny
parasol rather than without
-
That's... one way of avoiding SQL injection and XSS.
I sure hope you've used a \ then.
-
That's... one way of avoiding SQL injection and XSS.
I sure hope you've used a \ then.
At least it's not an important account. They just have my entire retirement savings and HSA.
-
Someone forgot to add the proper redirect on logging out from the timesheet methinks.
Not My Problem! Go make a
nullwebpage and this will work!
-
WTF of my day: Recently I found myself in the inner city of Hamburg on the search for a parking space. Acquired one, then set off for the parking meter machine 50 meters away where I got the required ticket. While doing so, I noticed the large amount of stickers proclaiming that I could easily get that ticket through an app as well.
Did some research when at home again and found that to be the case. Also found a company which offered no base fee and rather low costs, calculated down to the minute. They also offered a timer to ask you: "Still parking there?" so that you would not forget to stop the meter and thus accrue several hours unneededly.
They offer three ways of paying: Invoice via letter (costs 2.50€), invoice by email (free) or payment by credit card.
I chose the latter. That's where the fun began. I've got two cards, one is from Barclay, the other from Hanseatic (this one I actually have only because they were the first to offer ApplePay)
Took the Barclaycard, entered the info, got this "3D secure" field ... which crashed out. "Error at the redeeming point".
I mailed them about this and got the answer: "Well, make sure that your card is enabled for online payments and such!" to which I answered that it is. Plenty of other services have no issue with this card.Answer: "Well, then contact your bank!"
Okay? On to the next card (Hanseatic). Crashed out as well, this time it was a "communication error". Mailed them that as well and, you guessed it, I should contact my bank about this because it surely cannot be their payment processor's error!
Fun fact: I wrote them that I used the Hanseatic card. They talked about the Barclayscard.
But the support person also gave me a direct quote from their payment processor's answer:
It's seems that this transaction had issue D03 = denied to connection issue to your acquire, we have not got info from the bank why so we don't have more deep info then denied due to acquier issues.
I wrote them that I will not be their problem solver, they don't pay me for that. I also wrote them that this is an issue firmly on their side of the equation. And finally, that, with this mastery of English, it's no wonder they "not got info" from the bank and they should search for another payment processor.
In the meantime, I'll use another app.
-
@Rhywden Is that an official part of the parking system, or a third-party add-on?
In Prague they introduced parking fee system a few years back, with an official app from the start (and in many places you will even have problem to find a parking meter). It is fairly basic, but it works, and it is done as a progressive webapp, which I consider reasonable for this kind of use-case—no app stores, just open it in a browser and create a shortcut.
-
@Bulb From what I've seen, here in Hamburg (and other places) they opted for a different method: An open API the various vendors have access to. The vendor basically supplies this API with the info "car with license plate number
Fooin zoneBaris valid sinceBaz" and the meter maids then access this API to see whether a parked car is registered there.This allows the vendors to have differing pricing and such.
So, if this particular vendor does not work out, there are about 10 others I can use as well.
-
@Rhywden I hope they've got the authentication on the write side of that API right…
-
@dkf Well, I kind of hope they haven't, it would be great to have self-certified free parking for the tech savvy!
-
-
Anyone see a problem with this?
oc.shiftId == replaced.shiftId && oc.sequence == replaced.sequence oc.scheduleId == replaced.scheduleIdBecause I sure didn't for a while. As usual, I am
-
@Benjamin-Hall why is that not a syntax error?
-
@Benjamin-Hall why is that not a syntax error?
Because in "modern" languages (well, Kotlin), there are no semicolons. The full statement was
val index = occurrences.indexOfFirst { oc -> oc.shiftId == replaced.shiftId && oc.sequence == replaced.sequence oc.scheduleId == replaced.scheduleId }So it was doing that first part, inserting a semicolon/statement end, then doing the last line and getting true for the first one and calling it good. Basically throwing away the first two checks. If I'd have put it all on one line, it would have been a syntax error.
-
@Benjamin-Hall said in WTF Bites:
Because in "modern" languages (well, Kotlin), there are no semicolons.
-
@Zerosquare said in WTF Bites:
Back to actual WTF bites:
Child tweets gibberish from US nuclear-agency account
The tweet “;l;;gmlxzssaw", posted to US Strategic Command's Twitter account, causes confusion.
Wonder how many AIs are using this account in their mix of tea leaves from which to read the future of the stock market.
-
@Benjamin-Hall said in WTF Bites:
Because in "modern" languages (well, Kotlin), there are no semicolons.
At least Kotlin does allow semicolons, so if you prefer the semicolon syntax you can use it.
-
@Benjamin-Hall said in WTF Bites:
Because in "modern" languages (well, Kotlin), there are no semicolons.
At least Kotlin does allow semicolons, so if you prefer the semicolon syntax you can use it.
h'mm... JVM languages are all semicolon transparent, in general... this speaks to a transparency that could be exploited for a sideband ZISC/OISC channel.
-
Status: Since nobody made this year's free topic on the foolish day, I'll document an instance of stupidity instead.
See, I play the game Star Trek: Fleet Command, a mobile farm simulator with pay-to-win PvP combat. This year's April Fools event was to collect tribbles.
This is done, natch, by opening chests of random loot. There are two redemption options, one which primarily gives Tribbles (which score points) and cosmetic items, and one that is supposed to give more chests and a reduced amount of Tribbles. These are called "Feed the Hungry Tribbles" and "Grow More Grain", respectively. Each player gets 80 chests for free.
Now, I'm not an agriculture specialist, but when I see "grow more grain", that indicates a guarantee of at least a portion of my original investment, if not some amount of profit, right? Otherwise, why would I do it? In other words, in theory I should have returned to me a significant portion of what I put in with this option, if not some amount of gain.
This is, frankly, not so.
I'm not a statistician either, but in theory if I pull ten grates, my odds of getting a single ten-crate return should be at least 50%, right?
Instead, after pulling all 80 of my crates, I received in return six (6!) crates in total.
Fuck lottery gamification....
-
@Benjamin-Hall said in WTF Bites:
Because in "modern" languages (well, Kotlin), there are no semicolons.
At least Kotlin does allow semicolons, so if you prefer the semicolon syntax you can use it.
Allowing it is utterly pointless, because it will still get insert it in case you didn't intend it and forgot something else that would force the statement to continue. In fact the most reasonable guideline for JavaScript is to not terminate statements with them normally and prefix certain symbols when they start a line with it and it is not meant to be a continuation. I am not sure how different the Kotlin rules are from JavaScript though; a reasonable guideline there is probably different, but I am sure it is to omit the newlines too.
-
@Bulb according to @pie_flavor, who's a huge Kotlin fan, Kotlin's semicolon rules are very reasonable. According to me, who's actually done research, they're exactly the same as JavaScript's.
-
@Gąska I suppose they are less of a pain in Kotlin as the static typing catches most mistakes immediately that JavaScript only finds at runtime. There also do seem to be some differences, e.g.
(prevents previous line from autocompleting semicolon in JS, but apparently not in Kotlin (unless I misread the incomplete definitions around the web). I still find Python's the most complicated rules for terminating statements with newline that are still obvious and easy to use (newline ends statement always except inside any kind of brackets).
-
There also do seem to be some differences, e.g. ( prevents previous line from autocompleting semicolon in JS, but apparently not in Kotlin.
Because Kotlin is one of those "functional-esque" languages where everything is an expression, including code blocks. JS doesn't insert semicolons inside parentheses because there exists no valid expression that could possibly be formed if there was a semicolon inside parentheses. Whereas in Kotlin, that's perfectly fine in some cases.
-
I still find Python's the most complicated rules for terminating statements with newline that are still obvious and easy to use (newline ends statement always except inside any kind of brackets).
Doesn't Python treat newline symbol as statement terminator always unless escaped? It always seemed very straight forward to me.
-
There also do seem to be some differences, e.g. ( prevents previous line from autocompleting semicolon in JS, but apparently not in Kotlin.
Because Kotlin is one of those "functional-esque" languages where everything is an expression, including code blocks. JS doesn't insert semicolons inside parentheses because there exists no valid expression that could possibly be formed if there was a semicolon inside parentheses. Whereas in Kotlin, that's perfectly fine in some cases.
That's not what I mean. I mean in JavaScript if you write
something (another)it will be parsed as
something(another)(a function call), but the examples I quickly found for Kotlin suggest there it will be two statements (that are both clearly valid, because you are free to ignore a value) at least in some cases.I still find Python's the most complicated rules for terminating statements with newline that are still obvious and easy to use (newline ends statement always except inside any kind of brackets).
Doesn't Python treat newline symbol as statement terminator always unless escaped? It always seemed very straight forward to me.
No. Unless escaped or inside any kind of brackets. I almost never
\-escape newlines in Python, but still have plenty of continuation lines inside list and dict literals and long argument lists.
-
There also do seem to be some differences, e.g. ( prevents previous line from autocompleting semicolon in JS, but apparently not in Kotlin.
Because Kotlin is one of those "functional-esque" languages where everything is an expression, including code blocks. JS doesn't insert semicolons inside parentheses because there exists no valid expression that could possibly be formed if there was a semicolon inside parentheses. Whereas in Kotlin, that's perfectly fine in some cases.
That's not what I mean. I mean in JavaScript if you write
something (another)it will be parsed as
something(another)(a function call)Oh, I see. Didn't know that.
Okay, so Kotlin rules aren't the same as JS - JS is a little more retarded.
I still find Python's the most complicated rules for terminating statements with newline that are still obvious and easy to use (newline ends statement always except inside any kind of brackets).
Doesn't Python treat newline symbol as statement terminator always unless escaped? It always seemed very straight forward to me.
No. Unless escaped or inside any kind of brackets. I almost never
\-escape newlines in Python, but still have plenty of continuation lines inside list and dict literals and long argument lists.Yes,
you are correcter than me. Still seems very simple.
-
Okay, so Kotlin rules aren't the same as JS - JS is a little more retarded.
JS makes the next line a continuation in most cases where it can be. If it was always, it would be fairly reasonable, but there are some important exceptions like after
returnthe semicolon is inserted eagerly, which make it pretty brain-damaged (I guess so you don't accidentally continue anif (something) return—in this light I am big fan of the inverted parenthesizing that e.g. Rust has,if something { block }which greatly reduces the risk of mixing those up).In contrast, Kotlin seems to only make it a continuation if it has to.
-
-
@Tsaukpaetra yes, it's called babel.
