С клиента - ajax. Вообще реализация больше к серверной стороне-обработчику относится(php, asp, perl или чего там у вас).

Alcorn, никакого ajax для перезагрузки картинки не надо? делается примерно так:
а вот сама капча формируется на стороне сервера

Вспомнил зачем мне нужен был аjax. Клиенту передавал номер капчи. А при submit сравнивал переданый номер капчи при загрузке страницы клиенту и номер капчи, хранящийся в переменной сессии. Если не совпадали номера, то сразу выдавал ошибку ввода без дальнейших проверок на правильность ответа, т.е. идентификация была вида капча-капча, ответ-ответ.

Один ответ-ответ тогда не делал по причине того, что ответы на несколько капч могли быть одинаковы.
При обновлении писал новый номер в hidden, тут ajax и нужен был.

Apay, а можно спромить, зачем мы передаём id?
и ещё вопрос:
Вот ф-ция:
[PHP]function newImg() {
document.getElementById('img_captcha').src='http://soc.ru/capcha.php?id='+Math.floor(Math.random()*10000);
}[/PHP]
а вот html

у меня картинка сначала выводится, но не обнавляется при клике...

dimjan4, id - произвольное число, передается для того чтобы браузер брал картинку не из кэша, а считывал по-новой (как-бы считает что картинка другая), и еще в captcha.php надо через header-ы "Pragma" отключить кэширование (погуглите как отключить).
все дожно работать, если нет - что выводится в error console?

Alcorn, это делается без ajax, примерно так
капча генерится и сохраняется по переданному id

Надо будет попробовать с src. Пока теоретически в моём случае от ajax можно избавиться. Идея такова:
есть див, в нём рисунок и hidden. При нажатии на обновить, просто перегружаем див, автоматически меняется рисунок и значение в hidden.
С id для браузера теперь понятно стало. У меня хранится немного другой id, именно реальный id самой капчи(хотя можно хранить просто левое число).

Пример:
В базе всего две капчи с одинаковым ответом. Чтобы эти капчи были разные, после генерации, счётчик капчи в бд сохраняю в переменной сессии, это же значение передаю клиенту при загрузке страницы. Далее при проверке(при submit формы) сверяю номер капчи на сервере и номер капчи на клиенте(капча=капча), если не совпал, то выдаю ошибку, если совпал, то лезу в базу данных и считываю ответ на капчу, при совпадении ответов(ответ=ответ), пишу в базу новые данные.
Это позволяет при одинаковых ответах исключить совпадения.

Для большей безопасности и исключения перебора, можно с сервера генереривать просто случайное число, а не передавать реальный id капчи и рисунок выводить не под реальным именем, а через сгенерированое рэндомом.

Но эти доработки уже лень было делать.

P.S. капчу делал сам с нуля, логику работы тоже сам придумал, поэтому могут быть ошибки.

А src применим ли к диву или опять упираемся в innerHTML и ajax...

Можно использовать iframe, через src его перегружаем и автоматом заполняется новый рисунок и hidden.

Или как вариант не обращать внимания на повторы, менять только рисунок и сверять по ответам.

зачем все эти сложности? генерится картинка и код на картинке сохраняется в сессии по имени переданного id, если при получении формы переменной сессии и таким id нет или она не совпадает с введенной капчей - показываем кукиш

Иногда посещают безумные идеи. Передачу id картинки клиенту можно оформить так:
при загрузке передаём id капчи клиенту, клиент вводит ответ на капчу, через "исключающее или" накладываем id на ответ, далее ассиметричным шифром(например RSA) шифруем всё это дело и отправляем на сервер, на сервере накладываем ответ из базы на id капчи и шифруем, теперь сравниваем результаты сервер-клиент, если совпали, то введены верные данные. Ещё можно для большей уверенности после "исключающего или" наложить сверху генерируемую клиентом соль(salt).

Это даст защиту от снифферов, зачем она нужна при пересылке ответа на капчу(не пароль же отправляем), пока не знаю :rolleyes:.

Если клиенту id не пересылаем, тогда вообще всё легко, картинку только меняем, сравниваем ответы и всё. При большом количестве капч можно даже id не сохранять, вероятность рэндома этой же капчи мала.

Вышеописанным способом логин и пароль паредаю на сервер, капче тоже видимо досталось. Если убрать ajax и передачу id клиенту, наверное ничего нехорошего не произойдёт, о результатах напишу(если решусь капчу переделать).

P.S. Если посмотреть со стороны спамеров, имеет ли смысл снифферром коллекционировать ответы на капчи и url для последующего спама сайтов, на которых был пользователь на заражённом компе и вводил ответы на капчи? Ну соберёт сниффер несколько капч с www.x.ru, а дальше... постоянно сабмитить в надежде попасть на эти две капчи.

Ладно, много написал тут, пока хватит.