1,368 reputation
2822
bio website marcelogibson.com
location Belo Horizonte, Brazil
age 31
visits member for 2 years, 3 months
seen yesterday

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


Apr
2
awarded  Notable Question
Mar
10
answered Storing passwords in reversible form - a genuine use-case
Jan
31
comment What are the implications of storing sensitive data in bookmarklets?
BTW I'm not a native english speaker, forgive me if I wasn't clear enough
Jan
31
comment What are the implications of storing sensitive data in bookmarklets?
@Rell3oT oh, sorry for the confusion! You were commenting on the suggested protocol, right? I thought you were suggesting an alternative to using bookmarklets... The intent here was to: a) when a password is defined, create a bookmarklet link [in the client itself] and drag it to the favorites bar; b) when the user wants to log in again, just click in the bookmarklet and the browser will load the page and provide the login credentials. However, the protocol is here just to frame the question - which is really about "the act of storing credentials in the favorites bar".
Jan
30
revised What are the implications of storing sensitive data in bookmarklets?
added 700 characters in body
Jan
30
comment What are the implications of storing sensitive data in bookmarklets?
@Rell3oT Sorry, I don't understand what you mean. The purpose behind "storing" some data is that it should still be there next time the system is started. So suppose I send the data to the iframe to be stored, what will the iframe do with it? Send to the server? That would require me to authenticate with that server, so I'm just moving the problem elsewhere, not solving it... But if that iframe stores it in a cookie, then it will be available [in the same browser] even after a restart, until the user clears his cookies of course. That's how I interpreted your suggestion.
Jan
30
comment What are the implications of storing sensitive data in bookmarklets?
@Rell3oT Do you mean, storing it on a cookie from a trusted domain? I do have a trusted server (the one that provides the JavaScript code - or else this whole client-side encryption thing would be pretty pointless...), in fact the main page is in the context of that server (the "less-than-trusted" storage server is the one that needs sandboxing), so no need to mess with postMessage (maybe except to transmit the authentication key - that the storage server will receive anyway). Your suggestion does not answer the question, but is indeed very helpful in my particular case!
Jan
30
comment What are the implications of storing sensitive data in bookmarklets?
"the user and their systems administrators may not understand that the need to protect it" Very good point! About using password managers, I'll surely support it in my system, it's a lot better than the alternatives (saving in the clear, remembering a weak password, reusing passwords). However, that's beside the point of the question... (i.e. you assert that it's less protected, but don't provide any arguments to support it) In any case, if the OSes are providing better and better suport for properly protected passwords, then soon my question may become moot.
Jan
29
revised What are the implications of storing sensitive data in bookmarklets?
clarification over my particular case
Jan
29
asked What are the implications of storing sensitive data in bookmarklets?
Jan
14
awarded  Yearling
Nov
13
awarded  Enlightened
Nov
13
awarded  Nice Answer
Oct
22
answered How safe is it to provide my administrator account password for a 3rd party software: EasyUS Todo Backup?
Oct
9
awarded  Popular Question
Jul
26
awarded  Nice Question
Jul
24
comment PHP web application security
@DaGhostmanDimitrov To illustrate why reusing IV is bad, check this funny example. Some modes of operation (such as CTR) will fail catastrophically if two or more data are encrypted with the same IV, others (like CBC) will offer some resistance but still collapse in the end (especially if an attacker has access to many ciphertexts). Source
Jul
24
comment PHP web application security
@DaGhostmanDimitrov Please read more about symmetric encryption, otherwise you're bound to make a mistake. While you can encrypt a lot of data with a single key per user, reusing an IV can literally void the security properties of a given cipher/mode. Don't worry about the confidentiality of your IVs, just make sure that there are different ones for different data and that they are unique (store them in the DB alongside the data). About your other concern, please see the 3rd paragraph of my answer and the update in the bottom, that might shed some light on what you're looking for.
Jul
24
revised PHP web application security
added 822 characters in body
Jul
23
comment PHP web application security
Could you please clarify whether you're concerned with one user accessing data from other users, or just with an external attacker accessing data from any of your users? Also, I'm assuming the server itself is trusted, i.e. it can access data from every user. Otherwise, things would get a bit tricky...