Twitter urges users to change passwords after computer 'glitch'
341–350 of 490 posts
Re: Twitter urges users to change passwords after computer 'glitch'
#342Re: Twitter urges users to change passwords after computer 'glitch'
#343This is a bad idea, but if you are required that your uses have passwords, you could use their password to seed an elliptic curve private key to create the user key on the fly.
Re: Twitter urges users to change passwords after computer 'glitch'
#344At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point
It is exactly the same problem.
Re: Twitter urges users to change passwords after computer 'glitch'
#345Earlier quoted context omitted.
So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?
nah, that just makes the "hashed password" the equivalent of the cleartext password. Whatever it is your client sends to the server for auth is the thing that needs to be protected. If the client sends a "hashed password", that's just... the password. Which now needs to be protected. Since if someone has it, they can just send it to the server for auth. But you can do fancy cryptographic things where the server never…
Re: Twitter urges users to change passwords after computer 'glitch'
#346Earlier quoted context omitted.
This is why you should turn on compiler warnings and heed them. It would have caught this.
Yeah, exactly. This error shouldn't ever happen, period. All modern development tools give big fat warnings when you do this.
> if a = 3:
^
SyntaxError: invalid syntaxRe: Twitter urges users to change passwords after computer 'glitch'
#347At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point
Re: Twitter urges users to change passwords after computer 'glitch'
#348At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point
Re: Twitter urges users to change passwords after computer 'glitch'
#349Earlier quoted context omitted.
What if you’re on someone else’s machine?
Not GP, but KeePass user: I store my KeePass database on a small thumb drive (SanDisk Cruzer Fit), together with a copy of the KeePass executable. If I absolutely need to decrypt my password database on someone else's machine I can take the "secure" software from the USB and hope for the best. The USB also stores a copy of Truecrypt and a large Truecrypt container with backups of my encrypted private keys (PGP, SSH).
Re: Twitter urges users to change passwords after computer 'glitch'
#350At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point
Maybe you should explain them there is a reason why passwords input is hidden in terminals: to avoid them being kept in ~/.bash_history. It is exactly the same problem.