y0ghur7_xxx
Joined 18 years ago
Karma
2,612
Submissions
597
Member since
May 15
Recent submissions
Comment · 7 years ago
Comment · 7 years ago
> They fail because of severe checklist fatigue
> checklists often leaves a lot to be desired.
You say yourself that checklists are great, and it is proven that they save lives. So if there is fatigue in using them over and over, and they are not perfect, well... get over it? Sure i can understand that it's boring to go through the same checklist 5 times a day, but come on, there are lives at stake here. If one of your wife patients gets an infection and dies because she forgot some important, simple, step because of "checklist fatigue" how would she feel?
Comment · 7 years ago
> Certificates which are perfectly good for communication and do not pose any significant security risk.
Is it so? I remember that in 2008 someone was able to create a rouge CA certificate because of the predictability of serial numbers[1]. It was a different time: we still used md5, but are you sure the limited entropy used to generate serial numbers does not pose any security risk?
Comment · 7 years ago
Actalis is a major Italian CA that works mainly with big banks and the public sector, like (from the bug report)
- the Tuscany Region (e.g. O=Rete Telematica Regionale Toscana, etc.)
- the Piedmont Region (e.g. O=CSI Piemonte, etc.)
- central public government (eg. O=Bank of Italy, Ministry of Transports, etc.)
- major banks (e.g. O=Unicredit S.p.A., FinecoBank, etc.)
- large private companies (e.g. O=SNAM, Terna, Wind, etc.)
- chambers of commerce
Comment · 7 years ago
It has to be baked into the CA, so that a browser vendor can check it before inclusion. If the CA specifies domains it is not allowed to sign certificates for, it will not be included.
Comment · 7 years ago
There is a Name Constraints extension in X.509[1] that does exactly that, but to my knowledge no browser implements it.
Comment · 7 years ago
The referrer header is in no way a tool to differentiate real users from a ddos attack.
Comment · 7 years ago
> but is this a common sentiment
It is. One more statistical point: I started reading, saw that phrase, closed the tab and came here for the comments.
Comment · 7 years ago
It's not scanning only port 3000:
const portsToTry = [
80, 81, 88,
3000, 3001, 3030, 3031, 3333,
4000, 4001, 4040, 4041, 4444,
5000, 5001, 5050, 5051, 5555,
6000, 6001, 6060, 6061, 6666,
7000, 7001, 7070, 7071, 7777,
8000, 8001, 8080, 8081, 8888,
9000, 9001, 9090, 9091, 9999,
];
Comment · 7 years ago
That's awesome. I hope that all asian phone manufacturers like xiaomi, sony, samsung, and others get together and make an alternative to ios and android. They are big, and they can pull it of. Android apps compatibility is a big plus. Finally some movement in the market.
Comment · 7 years ago
I don't think so: neither of those tools sign the message with the same RSA keypair. sshenc.sh for example does not sign the message whatsoever. An attacker could just intercept a ciphertext, drop it, encrypt a different message and send that.
Those tools are not meant for sender authentication. If you want that you would have to first share the senders pubkey with the recipient, and sign your message with the corresponding privkey.
Comment · 7 years ago
> @Benjojo12 and I are building an encryption tool that will also support SSH keys as recipients, because everyone effectively already publishes their SSH public keys on GitHub.
Is this not already possible with tools like https://ssh-vault.com/ and (shameless plug) https://sshenc.sh/?
Those tools use the RSA keys to encrypt a symmetric key that is then used to encrypt the data, but the outcome is effectively the same. No?
There are still some people there, and talking about stuff. It's very much like hacker news, but with much less people :)