| bio | website | marcelogibson.com |
|---|---|---|
| location | Belo Horizonte, Brazil | |
| age | 30 | |
| visits | member for | 1 year, 4 months |
| seen | yesterday | |
| stats | profile views | 43 |
Work mostly with Python and JavaScript, but have some background in a wide range of languages and programming paradigms. Dream of designing my own language someday... Also interested in game design (as hobbyist), and always looking for new ways technology can help mankind achive a state of peace and prosperity, for everyone.
My company: Diferencial Consultores Associados
Fala Português? Se você se interessa por desenvolvimento de software, siga a proposta Stack Overflow (in Portuguese)
|
May 18 |
comment |
Do websocket-powered web apps (e.g. “comet” apps) have to worry about CSRF? @Adnan new attempt... you're right that the previous answer was uninformed, and I really appreciate the feedback, but I disagree it had nothing to do with CSRF: I was simply breaking down the elements that allow such attacks to take place (something I made more explicit after this edit) and commenting on how much each of them applied to WebSockets. And the "speculations" were simply more questions that - while I didn't/don't have a definite answer to them - I judged important in evaluating whether or not the assumptions we make about the browser behavior are correct. |
|
May 18 |
revised |
Do websocket-powered web apps (e.g. “comet” apps) have to worry about CSRF? added 1395 characters in body |
|
May 18 |
comment |
Do websocket-powered web apps (e.g. “comet” apps) have to worry about CSRF? @Adnan ok, thanks for the info, I'll read more about the RFC6454. But in face of this, I guess this answer is unsalvageable, so I'm deleting it... |
|
May 18 |
answered | Do websocket-powered web apps (e.g. “comet” apps) have to worry about CSRF? |
|
May 15 |
comment |
Are CSRF Attacks Really Blind @curiousguy "The mere fact that I might have to worry about a potential, unlikely, problem is annoying" Unfortunatly that's the reality of web application today - too much is left unspecified, too much vary by implementation, too much require trust in the user agent. I agree with you especially on the "future" part, since every new feature browsers introduce usually come with new security holes (either in spec or impl). However, if these specs are corretly implemented, I believe CSS should be safe in this regard... |
|
May 15 |
comment |
Are CSRF Attacks Really Blind @curiousguy yes, but I'm saying in the context of a CSRF attempt, i.e. you pick some URL in the target site - which will return sensitive data in some format - and use that URL in the href attribute of a link tag. And it's unlikely that a web service would return sensitive data in CSS format, right? (though I dunno how different browsers would react to malformed CSS, so it's a good point nonetheless) |
|
May 14 |
answered | Are CSRF Attacks Really Blind |
|
May 14 |
comment |
Bruteforce Passphrase of Dictionary Words @DanKanze There's no way to improve time if hashes/KDFs are used correctly. For instance, a key to decrypt a file can be derived from a password using PBKDF2 with 10000 iterations. There's no [easier] way to get that key without entering the right password and performing those 10000 iterations (i.e. brute-forcing the key will take a lot longer, since there are many more possible keys than passwords). If you increase to 1m iterations, the number of guesses per second will drastically decrease, but the legitimate users will be annoyed to wait several seconds/minutes for the file to open. |
|
May 14 |
revised |
Bruteforce Passphrase of Dictionary Words added 472 characters in body |
|
May 14 |
comment |
Bruteforce Passphrase of Dictionary Words @DanKanze The difficulty of performing the hash function itself is what throttles the guess attempts. In other words, even with the CPU/GPU running at full power, it's not possible to peform more than X guesses per second. To learn more about the subject, I'd suggest starting with this question |
|
May 14 |
comment |
Bruteforce Passphrase of Dictionary Words @DanKanze most hashing algorithms used with passwords (bcrypt, scrypt, PBKDF2) provde a configurable working factor, that allows you to make it harder or easier to perform each guess depending on your needs. Your goal is to make it as hard as tolerable for legitimate users (i.e. how long they can wait for a successful login to happen) so the attackers will be able to perform less guesses per second. |
|
May 14 |
answered | Bruteforce Passphrase of Dictionary Words |
|
May 9 |
comment |
Standard algorithm for WEP key generator 64-bit Please don't cross-post the exact same question in two or more SE sites, even if it would be on-topic on both. See this FAQ entry for more details. Thank you |
|
May 8 |
comment |
When salting and hashing passwords, any advantage to including password length? @Bobson assuming the attacker knows your hashing protocol (otherwise you get a little additional security by obscurity) I'd say "no". The hash gets a little slower - which is a desirable property when hashing passwords - but as I said the benefit is neglibigle. Better increase the work factor of your hash instead. |
|
May 8 |
answered | When salting and hashing passwords, any advantage to including password length? |
|
May 8 |
comment |
Can clients execute my python CGI at will? @Xan if your webserver is configured to execute the python scripts and return the result, instead of returning them as-is, then no, the users won't be able to see your sources. Unless of course there's some misconfiguration in the webserver, then your scripts may temporarily leak until you make a fix (seen happening before). About the www, I think Adnan meant that only the scripts that the user will run should be in cgi-bin, the rest (that the users must not run directly or even see) should be in a place that the webserver will not run them (or return them, in case of a misconfig). |
|
May 8 |
answered | Can clients execute my python CGI at will? |
|
May 7 |
answered | HTTPS firewall rule |
|
May 3 |
comment |
How secure is TeamViewer for simple remote support? Good point! It's very easy to forget this detail, and you never know what is in the clipboard at any moment, since it's invisible... so I'd rather play it safe and disable this option. |
|
Apr 28 |
revised |
How are large tech sites such as LivingSocial, Zappos, LinkedIn and Evernote hacked? converted references to links |