I have to say, I missed the condescending tone of slashdot comments...nowadays they don't do it like they used to do.

In your comment I see an opinion that is repeated again and again however I see no real counterpoint. The MS-Style comment is just an appeal to the old-school hate of microsoft with no real essence. In practice though security is flawed act of compromise which we usually try to be "secure enough" and hope that breaking the security is hard enough that nobody has the knowledge or time to do it.

However, since we are going there, let me indulge in some shitposting too.

An automatic trigger of a plaintext password export through a config option is the dumbest sh*t you could ever implement in a password manager. Like for real! Such an action should not be able to be done automatically, let alone without a huge red banner. Not acknowledging that it's the dumbest sh*t and actually trying to argue that it's the OS fault that this is not insecure is so dumb that it's actually quite f*ing funny. Digging the graves of slashdot opinions from the 2000s along with the old-style hate of MS is hilarious!

The only reason that I have not laughed my ass off is because I actually use keepass and I like it, however now I question the level-headedness of the devs.

Security should always be approached in layers. The idea is that even if one layer is compromised (and it should be assumed that at least one layer WILL be compromised), the other layers will at least partially protect what needs to be protected. No single layer is 100% secure. The argument that someone can replace the executable, the expertise level for developing a compromised executable is vastly higher that just changing a config file with the OS supplied notepad.

Saying "oh the PC is compromised, all is lost" is a very nihilistic way of handling this issue. In the end, if this argument sticks, why not just use an excel file? The developers of keepass are very emotionally defensive and dismissive on this especially since as I understand a fix is quite simple and has no additional side effects

I'm going to assume that you are going for shock value/trolling here

Condescending much? You haven't used python for any amount of time, have you?

Your argument is a google search for "python sucks"? Java, C, ruby, go have more results. Go even has its own website: http://www.golang.sucks/

That's not a good summary, that's an ok summary. With the exception of list comprehension which becomes unreadable very quickly, most points are rather minor, or things that you learn to live with - as is the case with all languages. Admittedly the author doesn't try to prove that python is a terrible language, just that it's not great.

The 2 points I hate python for are:
1. Duck typing: For small programs it's fine. For bigger ones or with multiple devs, it becomes a mess quickly. Type hints don't help too much.
2. Performance: Javascript has shown that interpreted languages can achieve impressive performance results. Python has some way to go.

Other than that, almost everything else is vi vs emacs all over again.

Unite the people against the threat. Stop making wearing masks a political issue. Accept publicly that this is a very serious issue and should not be taken lightly. These are things that most leaders have done.

BTW, this is coming from a non-American so I don't really care about American politics.

Although I agree that SMS is a stupid way to do 2FA, the article got it completely wrong and the PSD2 directive doesn't state anything like that.

According to the linked document https://eba.europa.eu/document..., it says that SMS is not suitable as a possible knowledge element (table 3), however it is suitable as a possible possession element (table 2). So, strong customer authentication can be implemented using a password (knowledge) and SMS (possession).

I have experienced the abuse you are talking about in one form or another too. And I'm a 35yrs old white male. So does this behaviour start from you being female or the fact that you (and me) know much more and make much more money than the people starting the abuse?

Just sayin'

Yeah, because I'm sure that the engineering costs are small in order to build a new system and win 2-3 years of "opaqueness" until everybody gets accustomed to systemd.

obligatory...

I'm I the only one that has noticed that:

1. The official site has nothing about it
2. Broadcom has nothing on their site about a BCM2836
3. On the register photo, there is no RAM on the PI (it should be on top of the processor)

and many many more little things

Unethical? Whatever.
Having read the original "census", it was a cool hack and no harm was done, nothing more. I'm pretty sure he/they didn't go for vigorous scientific process when this was done.

From the disclosure:

Just sayin'....

Exactly!

The disclosure is very well written, says exactly why this is a big problem and proposes a very implementable solution that would fix it. Nevertheless, the dev decided to try to dismiss the disclosure, called his daddy (de Raadt) and they both threw a tantrum, and fixed it in a way that is questionable (an update on the disclosure raises some good questions on why it is questionable)

Btw, forgetting about ssl for a minute (open/libressl are crypto libraries, not ssl libraries), a PRNG is either secure or it is not. There is no "kinda" secure in most user scenarios etc.

the PIN vs signature subject (the cardholder verification methods) has more to do with who pays when the fraud happens. Signature is by far easier to use, and this is the reason why in europe it is usual for good customers (cards with expensive subscription fees etc.) to get chip and signature and low end cc and debit cards get chip and pin.

To me the problem is not the PIN, but the magstripe itself, which for europe is kept there for legacy reasons (and at this point, yes I am looking at you US...). If the magstripe was completely disabled then there would be no way to skim the card because you would lose one of the 2 required pieces of information (PAN/CVV).

The second problem is that even with the PAN/PIN, the card should be useless but again there are 2 problems.

1. is again legacy reasons. You steal the PAN, write it in a new card, enter the stolen PIN, bob's your uncle. This should not be possible if the cards where full EMV as the card itself is authenticated against Visa/Master PKI.

2. Internet purchases! Now this is a biggie. You don't want to inconvenience anyone so you keep it as easy as possible. No card authentication, no cardholder authentication. Everything goes. To me this problem can be best tackled with one time passwords/tokens generated by a smartcard.

As you understand this is not a technical problem - and I can assure you that the technology exists and it is solid, but an adoption problem and a backwards compatibility problem.

btw: Come on, you can't read Bruce Schneier and at the same time write the PIN on the back of the card. This is like writing your password on a postit and stick it on the screen. Sure, it's annoying but have some standards!

I don't have experience with the american market so your mile may vary. Having said that:

The terminals are usually sold by vendors that develop the software too. If a bank decides not to work with the vendor in order to develop the software (as in testing environments, proper specifications etc.) then you simply can't use a specific terminal device (reader if you like) with a specific bank/acquirer. As you understand this has to do more with business matters/politics, but nevertheless it is true.

Now the chip and pin/EMV vs magstripe only, if the bank doesn't support it, it is end of story which the OP mentioned. The specifications/requirements are simply too different.

Interestingly enough, EMV (c&p) cards work like this. However the card and the cardholder are both authenticated - either PIN or signature.

Ok, isn't it a bit stupid to design a system that can be circumvented by someone stealing your card? And no card deactivation for sure doesn't solve the problem