Wikipedia:Reference desk/Archives/Computing/2012 October 9
Computing desk | ||
---|---|---|
< October 8 | << Sep | October | Nov >> | October 10 > |
Welcome to the Wikipedia Computing Reference Desk Archives |
---|
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
October 9
[edit]Microsoft Word quote characters
[edit]Hi in Word 2007, when I use quotes it insists on putting in the characters ‘ and ’ instead of '. Is there any way of turning that off or forcing the '? I can do the most advanced things in computers but Word drives me nuts! Sandman30s (talk) 10:13, 9 October 2012 (UTC)
- Those are called "smart quotes". Info about how to disable that feature is here. -- Finlay McWalterჷTalk 10:19, 9 October 2012 (UTC)
- Thanks for that... would never have found that in Word's menu black hole. It seems to work and looks correct in Word; however there is one rogue line which, no matter what I do, when I copy and paste that line into notepad it still pastes the 'smart' quotes. The best part is that line looks correct in Word! Sandman30s (talk) 07:45, 10 October 2012 (UTC)
- And I agree, that's quite annoying. I've been copying Python code from lecture notes, in order to run it, and have to manually fix every case where the word processor did that to them. StuRat (talk) 10:22, 9 October 2012 (UTC)
- Why are you using Word for lecture notes? (Or, why is the instructor doing such a silly thing, as the case may be?) --Trovatore (talk) 06:40, 11 October 2012 (UTC)
- It's the instructor, and you'd have to ask him. StuRat (talk) 06:49, 11 October 2012 (UTC)
- In many modern code editors, there is a function somewhere called something like "Straighten Quotes" which converts all smart quotes to straight quotes. --Mr.98 (talk) 11:36, 9 October 2012 (UTC)
Short but strong passwords
[edit]I know, strong short passwords sound kind of like tasty, fat-free chocolate. Nevertheless one of the online services I use (and am required to use for my job, so don't say that I shouldn't use a service with such ridiculous requirements) has an 8 character limit (case sensitive, letters, numbers and symbols allowed). The consequences of this password being compromised are fairly high so I am interested in getting the best security possible. So, firstly, is even a randomly generated password of this length secure in this day and age? Secondly are there any tricks I can use to increase security e.g. will passwords generally recognise non-keyboard letters such as Greek or Chinese characters that probably won't be in brute-force character lists? Equisetum (talk | contributions) 15:34, 9 October 2012 (UTC)
- An online attacker (e.g. a botnet) will surely try passwords in order of likelihood, meaning they'll try the random-junk passwords (henceforth RJPs) last. For an online attack they probably won't bother with RJPs, as their bots or the account will likely get blocked or rate-limited before they get that far. Online attackers are looking for low-hanging fruit, mostly. For offline attacks (where an attacker has obtained a copy of the password database), with a rainbow table, they'll still try real words first, but 8 characters of rainbow table is quite tractable (particularly if the database isn't salted). There's no way of knowing, without trying, whether they'll accept non-ascii (or non-latin) characters - a sensibly written service will, but a sensibly written service doesn't impose such a low limit on passwords. If they do accept say Chinese characters then they're at least doubling the effective password length (depending on how they're encoding stuff). This is, as you say, an unsatisfactory situation, and there's not much you can do to ameliorate their decisions. A random password, unique to this service, is probably the best you can do. I'd write a memo detailing "what will happen when our account at XYZ online service is taken over", so you can scope the damage should that happen. -- Finlay McWalterჷTalk 15:51, 9 October 2012 (UTC)
- You might find this article interesting regarding offline hash cracking — apparently rainbow tables are more or less no longer needed, what with the speed of GPU hash crackers ("You can literally test all lowercase, alphabetic passwords which are ≤7 characters in less than 2 seconds. And you can now rent the hardware which makes this possible to the tune of less than $3/hour. For about $300/hour, you could crack around 500,000,000,000 candidate passwords a second."). --Mr.98 (talk) 02:16, 10 October 2012 (UTC)
- But what web sites allow you to try 500,000,000,000 candidate passwords a second ? If they require each to be sent separately, accepted or rejected, then this notification sent back to the user, this is going to introduce a much longer delay. StuRat (talk) 02:41, 10 October 2012 (UTC)
- Read it again — we're talking about "offline hash cracking". --Mr.98 (talk) 17:11, 11 October 2012 (UTC)
- The point is that, ideally, you want to assume that an opponent has somehow managed to capture the website's hash table, and you still don't want that opponent to be able to masquerade as you. --Trovatore (talk) 02:54, 10 October 2012 (UTC)
- I looked in to that blog post before and my understanding is it's somewhat mistaken about the use of rainbow tables. They are still widely used even with GPUs (in fact many rainbow tables require GPUs) because they can still speed up searches fairly significantly, I believe the blogger simply misunderstood how rainbiw tables are used. Nil Einne (talk) 03:54, 10 October 2012 (UTC)
- I doubt he's misunderstood that; he's saying that the speed of modern GPUs means you don't necessarily have to precompute tables. Having precomputed tables is fine and good, of course, and obviously if you use the same cracking software to precompute the tables, that only expands your capabilities. The main point of the post is that speed hashing has gotten to much higher levels than most people realize. --Mr.98 (talk) 17:14, 11 October 2012 (UTC)
- No he said:
Rainbow tables are huge pre-computed lists of hashes, trading off table lookups to massive amounts of disk space (and potentially memory) for raw calculation speed. They are now utterly and completely obsolete. Nobody who knows what they're doing would bother. They'd be wasting their time. I'll let Coda Hale explain:
- Which I'm pretty sure is wrong. See for example [1]. Note that you don't just use GPUs to precompute the tables. The tables themselves are designed to be used with GPUs. Note that I'm not questioning his basic premise simply pointing out one of his points is as far as I understand it, wrong.
- Nil Einne (talk) 00:24, 13 October 2012 (UTC)
- I doubt he's misunderstood that; he's saying that the speed of modern GPUs means you don't necessarily have to precompute tables. Having precomputed tables is fine and good, of course, and obviously if you use the same cracking software to precompute the tables, that only expands your capabilities. The main point of the post is that speed hashing has gotten to much higher levels than most people realize. --Mr.98 (talk) 17:14, 11 October 2012 (UTC)
- But what web sites allow you to try 500,000,000,000 candidate passwords a second ? If they require each to be sent separately, accepted or rejected, then this notification sent back to the user, this is going to introduce a much longer delay. StuRat (talk) 02:41, 10 October 2012 (UTC)
- Great advice, thanks. I think I should be reasonably okay with an RJP as this is a large system and there will be a lot of low hanging fruit around. Now... I just need a random password generator that I trust and to work out a way of remembering the output (don't worry about answering this - easy to google)! I don't think I'll even try non-ascii characters as I've just remembered a story from a while back of a piece of software (I think it was some turnkey forum software for websites) that would allow non-ascii characters but convert them all to spaces or something similar, turning the most secure passwords into the least secure at a stroke! Equisetum (talk | contributions) 17:02, 9 October 2012 (UTC)
- KeePass will both generate and store passwords. -- Finlay McWalterჷTalk 17:29, 9 October 2012 (UTC)
- Worst case scenario: they only allow letters and numbers, and the letters aren't case sensitive. This would give you 36 possible characters in each position, so 368, or over 2.8 trillion, possible passwords. If they can try one password a second, it should take almost 90 thousand years to try every possibility. As long as you use random characters, you should be fine. StuRat (talk) 23:20, 9 October 2012 (UTC)
You may be in trouble and if the data is sensitive, you may want to get your manager concerned. From the Linux journal - you probably have the hardware in your computer already and the cracking software is free. Zoonoses (talk) 06:34, 10 October 2012 (UTC)
- To know the best way to defend yourself against those types of attacks you need to know a bit about how software like this works. For example, there are 4 character sets.
- ?d – 0123456789
- ?l – abcdefghijklmnopqrstuvwxyz
- ?u – ABCDEFGHIJKLMNOPQRSTUVWXYZ
- ?s – !@#$%^&*()`~-_=+\|[]{};:'",.<>/?
- A password that uses all 4 character sets is stronger than a password that uses just one or two. Because of the character limit you should probably use a password like 3aA%9zX> that uses all charactersets twice. They (talk) 22:30, 11 October 2012 (UTC)
- To generate a strong password (or passcode), try this:
- Make a photo using a digital camera.
- Now run a checksum-generating program on the file.
- The checksum, if it's long enough, is your password.
- This assumes that
- The checksums are equally probable. Some freak layouts can cause this to break down, for example if the image file has a built-in check which works by making the checksum zero on every file.
- Noise will make the file contents largely random, that is, you can take 1000 "identical" photos and are likely to get 1000 different checksums on the files,
- The checksums are long enough. 32-bit checksums will be too vulnerable. 64-bit checksums will be quite safe for now. - ¡Ouch! (hurt me / more pain) 07:02, 17 October 2012 (UTC)
- To generate a strong password (or passcode), try this:
Least computing power, long time audio recorder
[edit]Have looked around for something that is just audio and is simple to use, one command and its recording to download, also one that can keep recording unlike the "Sound Recorder" on microsoft OS which keeps stopping every 60 seconds. Any program with "Sound Recorders" simplicity and low memory usage but that keeps going? Thanks. Marketdiamond (talk) 16:32, 9 October 2012 (UTC)
- Audacity is nice, but has a more sophisticated interface than you're looking for. GoldWave is reportedly simpler. SoX (particularly its rec command) is about as basic as one can get. -- Finlay McWalterჷTalk 16:42, 9 October 2012 (UTC)
- Thanks Finlay McWalter! Marketdiamond (talk) 21:57, 9 October 2012 (UTC)
Facebook's dynamism
[edit]Hi, How does the page of facebook is so dynamic? Is there a script behind it? I thought about it, but it can take a lot of resources from the server. Exx8 (talk) 17:46, 9 October 2012 (UTC)
- A good starting read for this sort of stuff is Ajax (programming). Not sure exactly what technique Facebook are using, but it'll not be 1,000,000 miles away. --Tagishsimon (talk) 17:49, 9 October 2012 (UTC)
- Facebook Platform describes the overall setup at Facebook. For desktop clients, they used to use an AJAX framework called FBJS, but they've replaced that with something called iFrames for Pages. For mobile sites they use a framework called Javelin, on which they build BoltJS. -- Finlay McWalterჷTalk 19:39, 9 October 2012 (UTC)
- I might be wrong, but Facebook Platform seems only to describe the app API, not the overall Facebook site itself. --Mr.98 (talk) 17:41, 10 October 2012 (UTC)
- The short, non-technical answer is a form of AJAX. In layman's terms, this means that your browser is constantly running a bit of Javascript that says, "Hey, Facebook's server, should I change anything?" If you hover your mouse over someone's name, for example, your browser says, "hey, what should I show this guy?" The server will give the script data ("Hey, put this guy's name and photo in here, and this list of shared friends"), and the script then tells the browser to display this. The "dynamism" is common to AJAX-like applications — it's all that Javascript working behind the scenes so that the browser doesn't ever have to refresh. As for the resources on the server, each individual call requires very little attention from the server — it's just text. (Even the photos are just text, because they are links to images, not the images themselves.) Now, if you multiply all of those little server requests times the millions of users — yeah, that adds up. It's non-trivial to code a site with the popularity of Facebook, as well as with all of those bells and whistles. You can make a very basic version of that sort of site with very little training at all, but getting one that won't crash or be sluggish when 100 million people do it at once requires clever programming, clever server architecture, and lots of processing and bandwidth capability. --Mr.98 (talk) 17:40, 10 October 2012 (UTC)
- I wonder if that explains the NASDAQ's feed of Facebook stock crashing the day of its IPO? Ok not funny for about 10 million ways.Marketdiamond (talk) 04:52, 11 October 2012 (UTC)
Problem with Wikipedia on Blackberry Curve
[edit]Over the last week or so I've noticed the format of articles has changed when I open up Wiki on my Blackberry Curve-when I click on the individual segments to open them up they do not respond. Have any other user's reported a similar problem?