|
What gets me is that I pulled up the registry settings on a pc that is known to successfully run the scripts and the offending key wasn't even there. Their system just defaulted to the server settings but because some previous owner of my work pc had explicitly set the date format in the registry, the scripts failed for me. Too many settings in too many locations makes for too many places for s**t to go wrong.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Which is why counting on implicit format mask settings is not recommended! None of those settings matter for anything other than display when you code with explicit conversions where you control the format mask. Otherwise, as you have discovered, you're walking an unknown dependency path waiting for someone else to set the default format for you!
Code with TO_DATE(string, mask) and the problem goes away - permenently!
|
|
|
|
|
Foothill wrote: I was more peeved at Oracle for not having any readily accessible documentation to help find some obscure registry key that causes string date conversions to fail just because they were out of an explicitly defined order. It's Chapter 15[^] in the Database Platform Guide.
|
|
|
|
|
Wow... that's spot on !
Thanks,
Milind
|
|
|
|
|
The secret to date literals in Oracle is to always use:
DATE'yyyy-mm-dd'
This format has worked with every SQL tool I have ever used. (At least 4)
|
|
|
|
|
|
Wow! I am weird but it looks like a ghost in red (the two outer spirals are arms)
|
|
|
|
|
Cool!
Get me coffee and no one gets hurt!
|
|
|
|
|
How can heavy computing be cloud based?
[Bit early. Happy Easter.]
Life is too shor
|
|
|
|
|
|
I hear heavy metal in the air.
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
...could be a Led Zeppelin
|
|
|
|
|
Let's say you compress a folder using WinZip or WinRAR with an AES256 encryption.
Let's say the password is 64 chars long (letters, numbers and special chars).
Would you trust this method to send sensitive and expensive data?
And if that file would be in not desired hands... how much effort would it take to decrypt it without the password?
Of course I don't expect receiving a precise answer like "yes, it will take 2 days and 34 seconds to decrypt the file..." just some comments and rough answers...
Thank you all!
|
|
|
|
|
My opinion based on what I have used so far - is that AES256[^] is perfectly safe for sending data.
Regarding a 64 char password, I don't see how you could communicate that outside on an email unless you write it down on paper and send it via courier. You could use a shorter password and be sure to communicate the password via a phone call or some other method that makes sniffing the data difficult.
In the past when I have worked with sensitive and expensive data, the data has always been handed over manually on an encrypted disk then the password has been communicated by phone(medical and patient data).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Joan Murt wrote: Would you trust this method to send sensitive and expensive data? No.
Such a long password will not be remembered, meaning that someone will write it down on a post-it.
Joan Murt wrote: And if that file would be in not desired hands... how much effort would it take to decrypt it without the password? If properly salted, too much to be worth the effort.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: If properly salted,
Don't forgett the pepper
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
|
Depends on the key size: How secure is AES against brute force attacks? | EE Times[^]
I'd say you are pretty safe (provided you aren't sending it from an Apple phone to ISIS...)
The way I'd do it if I was feeling paranoid is to zip it with a password, then zip the zip file as a spanned archive with a different password, and send the two (or more) zips separately.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Only if you don't use standard ZIP encryption, which is extremely weak.
Software Zen: delete this;
|
|
|
|
|
That's Zip 2.0 legacy encryption - my version uses AES 128 or 256 selectable.
(In the Actions pane on the RHS, turn "Encrypt" On. An "Options" drop down will appear. Choose "Encryption settings" and you can pick your method. Don't pick "Legacy" for gawds sake as it's as secure as a sock full of cash under the mattress).
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I would've started by not announcing to the rest of the world that it can eliminate the following when trying to brute-force your password:
a) letters-only passwords
b) numbers-only passwords
c) special chars-only password
d) passwords of anything but 64 characters in length
|
|
|
|
|
Joan Murt wrote: Would you trust this method to send sensitive and expensive data?
Only if it's on an iPhone.
|
|
|
|
|
I'm orf on holiday tomorrow, so you'll be free from me for a couple of weeks. Though I may check in now and then just to make sure there are plenty of sheep jokes.
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: plenty of sheep jokes.
Baa!
|
|
|
|
|