5,722 reputation
21044
bio website lucb1e.com
location The Netherlands
age
visits member for 1 years, 10 months
seen 6 hours ago

Software Engineering student. Also interested in computer networking and security. For contact info, see lucb1e.com/!about


Apr
18
comment Booting into Live USB Linux
@oshirowanen Your normal computer might have a virus to alter the USB stick's contents, that's why. Usually not the case I guess, but again, if you're talking about "usually" then much of the advice in my post can be disregarded.
Apr
11
comment Is Apache serving over HTTP vulnerable to Heartbleed?
@David Hmm, I'm not sure heartbleed+ssl/tls is better than no ssl/tls at all... I have first hand experience exploiting both and you're right that they're both awful, but the impact of http is usually much lower. Of course in different situations things might be different, but generally I think you're much better off disabling https altogether if the alternative is to leave it vulnerable.
Apr
11
comment API to change passwords?
@SteveS because then you rely on a central authority that is a single point of failure in availability and can also impersonate you. And as for multifactor: well you're down to one factor if your password leaks. Perhaps the second protects you for a while, but it was two factor for a reason.
Apr
11
comment Is Apache serving over HTTP vulnerable to Heartbleed?
@David, Actually, I think your comment is flawed :P. What you're saying is: "even with this bug, an attacker needs to be savvy enough to exploit it, whereas http can always be read in plaintext". There is a huge distinction here: with this bug you can read anyone's data from the RAM if you get a bit lucky, even the server's (i.e. its private key). With http you can only read the data from whomever's network traffic you can see. If http was equal to the heartbleed bug, we'd have banned plain http a long, long time ago (though, for different reasons, we should, and are in http v2.0).
Apr
9
comment Are there any known Heartbleed attacks?
Nice try, FBI. No but seriously, I don't think the kind of people that go around trying to exploit the internet are going to visit this site and tell you about it.
Apr
6
comment Why are apps for mobile devices more restrictive than for desktop?
First thought: Because they were designed far more recently with more modern needs in mind, and desktop OSes have yet to catch up.
Apr
5
comment Is Telegram secure?
@TerryChia I understand your point, and I too distrust any crypto in new apps, but I don't think this is the major concern when using Telegram right now. The protocol has been looked at by a few smart people and so far I've yet to hear actual issues, so that in my opinion that moves it from "distrusted" to "probably one of the lesser issues". Things like not having plausible deniability, leaking metadata, devices being pwned, people not comparing the encryption key out of band, etc. seem like much bigger issues when deciding whether one should say product X can be ultimately trusted.
Apr
5
comment Is Telegram secure?
In short, I'd say nothing is secure that works as easy as Telegram, WhatsApp, Skype, BlackBerry, etc. All of those (except WhatsApp) have promised end to end encryption, and so far only Telegram is not known to hand over their encryption keys to governments, simply because they are not big enough yet. Somehow Microsoft and Blackberry made it possible to break their own security and provide India and the United Arab Emirates with some plaintext. I wouldn't put it past any app to do this. For real security, use trusted tools like PGP/GPG or OTR.
Apr
5
comment Is Telegram secure?
Reiterates lots of the criticism, but so far I have yet to hear a non-theoretical vulnerability. Can anyone read encrypted messages as they go over the wire, change contents without the other party noticing (even if the attacker doesn't know what the decrypted output will be), or spoof the sender? If not, I don't see a problem with this self-designed protocol. All protocols have been designed by one team or another at some point.
Apr
3
comment Security of a Windows XP system after April 8th when running the latest Firefox or Chrome
"XP has had enough holes over the years that it's hard to imagine there aren't some un-found holes in what remains." I understand that, but you'll need to somehow reach the system to exploit it. So if the browser is the only way, and it's a modern and up-to-date browser... That's what I'm asking about. "an installation of linux" I've thought of that, but Windows 8 on her work laptop is a huge change already. I'll use this as a last resort. Thanks for the suggestion though!
Apr
3
comment Security of a Windows XP system after April 8th when running the latest Firefox or Chrome
Third party anti-virus already installed for the same reason as a third-party browser. EMET may be a good idea though, thanks!
Mar
21
comment How does SSL work?
@RosdiKasim Yes, you can do that easily. Data is unencrypted and can be manipulated until right before it is transmitted. That's the risk behind installing plugins. Rogue plugins are basically the same as running a virus with user (non-adminstrator) permissions: it may be confined to your user account, but it can still log all your keys (keylogger). In the case of a browser plugin it is confined to your browser, but it can still get all website's data (including passwords when you type them in).
Mar
19
comment Finding Hidden Keylogger Through Forcing a Computation Error
"Maybe this is something a bit higher than what most people on this site are able to answer" Honestly I think it's more beyond your comprehension, not the people on this site. It was a good laugh though to read you filming a screen at 16k fps when it only refreshes 60-120 times a second. Edit: Also to answer your question: 1. you can tap a line without slowing it down, and 2. you can do software keyloggers without introducing delay since you read the key after-the-fact instead of intercepting it (sudo cat /dev/input/*).
Mar
18
comment How safe is SSL?
TL;DR: yes it is all encrypted and secure. Even if it wasn't, there is nothing you can do about it. Adding hashing via javascript adds no security to https.
Mar
17
comment Why warning sign when visiting https-website?
It's a lengthy piece, but the answer is in here: security.stackexchange.com/a/20833/10863. Under the section "How to crack SSL," subsection "in detail," paragraph 2, it is explained what causes this warning sign.
Mar
12
comment Why am I allowed to access protected Windows files when I boot Ubuntu from USB?
@Emmet Yeah, very clever.
Mar
11
comment Is this where a nonce comes into play?
@user3379785 Note that comments aren't really meant for chatty back-and-forth stuff. The chat is usually recommended instead, but for some reason you need 20 reputation point to participate in the chat... If you have more questions on this topic you could email me or something. See https://lucb1e.com/!about for contact details. If you have a more general question (something that would be of use to others), you can always start a new question on this site.
Mar
11
comment Is this where a nonce comes into play?
@user3379785 The crux of the problem is that the GUID is both the unique way of referring to an account and it provides full access. So as long as the GUID can be used instead of username+password, I think the design could be improved (even if it's not directly broken, like I said in the post). You say the GUID is checked before API calls, but how is it checked? You mean the server checks whether the GUID matches the session's owner? So the GUID is not enough, you now also need to send the session id with API requests to control an account? In that case I think it's much more solid now :)
Mar
10
comment Is this where a nonce comes into play?
@user3379785 It could be, but it's probably much more practical to generate it only once and put it in a database column. Or generate it upon logging in and put it in a session file (or session table). Depends on the implementation.
Feb
23
comment How to encrypt more than 16 bytes using AES?
Short answer: see this Wikipedia article: en.wikipedia.org/wiki/Block_cipher_mode_of_operation