|
The team collaboration tool provider Slack is open sourcing a new tool designed to help developers secure features with high output and low friction. Because when you think 'security', think of a company named for 'characterized by a lack of work or activity'
|
|
|
|
|
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again. You are encouraged to change your password again. If you have reused the password on other sites, change those too 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Due to a bug
More like a severe design flaw 
Besides, shouldn't passwords be encrypted even before they are sent to the server? (whether using https or not) 
|
|
|
|
|
V. wrote: Besides, shouldn't passwords be encrypted even before they are sent to the server?
I'd go for "both". If only the client hashes, then that hashed piece becomes similar to a password; if I can steal it, I can use it as a password directly on the server, without needing the actual unhashed password.
The server should hash its data too, to prevent any (temp) workers from getting those tokens.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Besides, shouldn't passwords be encrypted even before they are sent to the server? I'd go for "both".
You think the client should encrypt the password before sending? The only way the client (a web browser, we're talking about twitter) could encrypt the data before sending is to use javascript and anything in js on the client can be reverse engineers (View->Source) and that includes your encryption algorithm and any passwords\secrets\keys you use to achieve the encryption. If a malicious person knows that information then your encryption is literally useless. That's what https is for, so you don't have to waste your time doing pointless things like client-side encryption on a website.
|
|
|
|
|
F-ES Sitecore wrote: You think the client should encrypt the password before sending?
No, hashed. With salt.
F-ES Sitecore wrote: The only way the client (a web browser, we're talking about twitter) could encrypt the data before sending is to use javascript and anything in js on the client can be reverse engineers (View->Source) and that includes your encryption algorithm and any passwords\secrets\keys you use to achieve the encryption.
Yes, they can; but they will have a hard time reproducing the original password. It would also mean that (thanks to SSL) this can only be broken if they have access to your local computer.
F-ES Sitecore wrote: That's what https is for, so you don't have to waste your time doing pointless things like client-side encryption on a website.
SSL is to secure transport.
Simpeler; SSL is a secure train-transport, but there will be loading and unloading of the cargo. You can just blindly hire such a secure train-transport and assume all is well, but that leads to the vulnerability that Twitter describes. There was an automated audit during unload, and it was theoretically possible that some employees saw the content.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: No, hashed. With salt.
You said encrypted, not hashed. Anyway, we'll run with your complete change in argument...what use is the salt if this is done on the client as the malicious user has access to the salt so that can be used to brute force the password. One of the reasons salt works is because it is unknown to the attackers.
|
|
|
|
|
F-ES Sitecore wrote:
You said encrypted,
I did not.
F-ES Sitecore wrote: One of the reasons salt works is because it is unknown to the attackers.
Duh.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: I did not.
V said "shouldn't passwords be encrypted even before they are sent to the server?" and you replied "both".
Eddy Vluggen wrote: Duh
So why are you advocating javascript-based hashing with salt if you're aware that it's pointless?
|
|
|
|
|
F-ES Sitecore wrote: V said "shouldn't passwords be encrypted even before they are sent to the server?" and you replied "both".
Yes, no direct intention on explaining the difference between hashing and encrypting.
F-ES Sitecore wrote: So why are you advocating javascript-based hashing with salt if you're aware that it's pointless?
It is not pointless, that's your opinion and you're entitled to it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It is not pointless
So why don't websites use it? Why is https such a big thing? You admitted yourself salt was not much use when the potential attacker knew what it was.
|
|
|
|
|
Which part of the truck analogy was too complicated? And it's rather simple to not share the salt 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Which part of the truck analogy was too complicated?
We're not talking about Twitter, we're talking about your belief that javascript security is a good idea, and why it actually isn't.
Eddy Vluggen wrote: And it's rather simple to not share the salt
Not if you are using javascript.
|
|
|
|
|
F-ES Sitecore wrote: Not if you are using javascript.
So who limits you to JavaScript on the client?
F-ES Sitecore wrote: We're not talking about Twitter
Correct, we're not talking at all.
F-ES Sitecore wrote: your belief that javascript security is a good idea, and why it actually isn't.
I do not believe anything. I know, or I'll verify, but belief is not my beef. I also haven't advocated JS security, you're jumping to conclusions again
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: So who limits you to JavaScript on the client?
We were talking in the context of major websites like twitter. If you're now saying that for the last 5 messages or whatever you weren't talking about js but some other as yet unidentified technology then I can't tell if you're waving or drowning.
|
|
|
|
|
F-ES Sitecore wrote: I can't tell if you're waving or drowning.
Why would I care about that? 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I'm not asking you to care, I'm saying that what you're saying is so implausible and flip-flops so much I don't know if you genuinely believe what you're saying or if you know your argument is dead but you're trying to save face.
|
|
|
|
|
F-ES Sitecore wrote: I'm saying that what you're saying is so implausible and flip-flops so much I don't know if you genuinely believe what you're saying or if you know your argument is dead but you're trying to save face.
That's not my problem
I also do not care how it looks, I'm not here to make a good impression. I'm here to help, voluntarily. I would also like to point out that your lack of understanding does not imply that I should try harder to school you. On the contrary, I'm going outside and have a great evening. If you want my expertise, I suggest you mail a decent offer as I do not feel inclined to share anything with you 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Any lack of understanding you think I have is a figment of your imagination, an attempt to divert attention away from the ridiculous things you have actually said on this thread such as web clients should be responsible for security. Enjoy your evening, but if this thread is an indicator of your level of expertise then don't wait by the door for that offer.
|
|
|
|
|
F-ES Sitecore wrote: Any lack of understanding you think I have is a figment of your imagination,
It may just be that you are incapable of reading of course
F-ES Sitecore wrote: an attempt to divert attention away from the ridiculous things you have actually said on this thread such as web clients should be responsible for security.
I will never point to a single item and make it responsible for security.
F-ES Sitecore wrote: Enjoy your evening, but if this thread is an indicator of your level of expertise then don't wait by the door for that offer.
Thank you, I will - there's chicken tonight
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It may just be that you are incapable of reading of course
The only opinion I've really offered has been to state that HTTPS protects the password in transport, everything else I've said has been trying to pin you down on your belief that the client should also be involved in security by encrypting or (as you later changed to) hashing with salt, and why you think those things are good ideas. You subsequently abandoned this to hint at some un-named technology should be used instead.
Eddy Vluggen wrote: I will never point to a single item and make it responsible for security.
I didn't say "solely responsible", but you said the client should encrypt\hash before transmitting ergo should be responsible. If you want to focus on the interpretation of words rather than your actual arguments then I guess you can't have a lot of faith in them.
|
|
|
|
|
F-ES Sitecore wrote: The only opinion I've really offered has been to state that HTTPS protects the password in transport
As the article explained, this one was leaked outside of transport. I gave you a VERY easy example to explain that.
F-ES Sitecore wrote: on your belief that the client should also be involved in security by encrypting or (as you later changed to) hashing with salt
I do not "believe", and despite your misquoting I did not go from encrypting to hashing. I also did not abandon any view.
F-ES Sitecore wrote: you said the client should encrypt\hash before transmitting ergo should be responsible.
That's a non-sequitur, quod Eddy demonstrandum.
F-ES Sitecore wrote: If you want to focus on the interpretation of words rather than your actual arguments then I guess you can't have a lot of faith in them.
You are focussing on pinning me; I'm focussing on whacking you and having fun. It is never going to be a productive "discussion", hence the suggestion to end it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: As the article explained, this one was leaked outside of transport
Why does that invalidate what I said?
Eddy Vluggen wrote: I do not "believe", and despite your misquoting I did not go from encrypting to hashing. I also did not abandon any view
V asked "shouldn't passwords be encrypted even before they are sent to the server".
You responded "I'd go for "both""
That suggests to me that you think the client should be involved in security? You then went on to defend the process of hashing with salt via js rather than saying "Oh, no, that's not what I meant" so that confirms that is what you believe. You then abandoned the js angle entirely by saying that it isn't the only technology you can use on the client, implying that perhaps you didn't mean js after all?
Are you aware that everything you have written is available for anyone to go back and look at?
|
|
|
|
|
F-ES Sitecore wrote:
Are you aware that everything you have written is available for anyone to go back and look at?
Yes, that's why I keep it going
You not amused?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
If I was clearly as wrong as you are and as equally determined not to admit it, I'd try and divert away from the actual issues too. When caught out I might even say I was just trolling, I hear that's popular with the kids today too.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
